C in RISC OS

From RISC OS

(Difference between revisions)
Jump to: navigation, search
(Add links, lose paragraph tags)
(Consolidate section on mixing SCL vs UnixLib)
(2 intermediate revisions not shown)
Line 1: Line 1:
-
The workings of C with RISC OS and its interactions with
+
The workings of C with {{RISC OS}} and its interactions with
various libraries often raise many questions.  All too often these
various libraries often raise many questions.  All too often these
questions are incompletely answered, leading to more questions or
questions are incompletely answered, leading to more questions or
Line 10: Line 10:
one is the ANSI C standard. Among other things, this defines what
one is the ANSI C standard. Among other things, this defines what
functionality must be present in a standard C library implementation.
functionality must be present in a standard C library implementation.
-
When the "Shared C Library" is referred to on RISC OS we
+
When the "Shared C Library" is referred to on {{RISC OS}} we
are talking about the library developed by Acorn which is ANSI compliant.
are talking about the library developed by Acorn which is ANSI compliant.
Line 27: Line 27:
does implement many of these, along with all the functions found in the SCL.
does implement many of these, along with all the functions found in the SCL.
Because of this, UnixLib can be invaluable when making Unix programs
Because of this, UnixLib can be invaluable when making Unix programs
-
work on RISC OS
+
work on {{RISC OS}}
While it is certain that UnixLib doesn't conform fully to POSIX, it
While it is certain that UnixLib doesn't conform fully to POSIX, it
Line 67: Line 67:
<ul>
<ul>
-
  <li><b>GCC</b>
+
  <li><b>[[GCC]]</b>
   <dl>
   <dl>
     <p>Inside the !gcc application are contained headers and library files
     <p>Inside the !gcc application are contained headers and library files
Line 82: Line 82:
     <pre>gcc -mlibscl hello.c -o hello</pre>
     <pre>gcc -mlibscl hello.c -o hello</pre>
   </dl></li>
   </dl></li>
-
<li><b>LCC</b>
+
<li><b>[[LCC]]</b>
   <dl>
   <dl>
Line 102: Line 102:
     </p>   
     </p>   
   </dl></li>
   </dl></li>
-
<li><b>Norcroft</b>
+
<li><b>[[Norcroft]]</b>
   <dl>
   <dl>
     <p>Norcroft is supplied with SharedCLibrary files.</p>
     <p>Norcroft is supplied with SharedCLibrary files.</p>
Line 126: Line 126:
==Mixing Libraries and Compilers==
==Mixing Libraries and Compilers==
-
Sometimes it is convenient to try and mix object files or libraries
+
It is possible to mix SCL and UnixLib-targeted AOF object files, but considerable care should
-
compiled with one compiler or targeted against different C libraries.
+
be taken. In general, it is discouraged, and rarely requiredUnder GCC 4 it is not possible,
-
 
+
since GCC 4 produces ELF object files instead, and these are soft-float rather than the traditional
-
In general, I would discourage this, unless you know what you are
+
RISC OS hard-float.
-
doing.  The reasons are as follows:
+
-
 
+
-
<ul>
+
-
<li><p>The size of the FILE structure varies between SharedCLibrary and
+
-
    UnixLib, as UnixLib has to hold more data to implement some POSIX
+
-
    functionalityThis means that programs accessing members of this
+
-
    structure will run into trouble.  Although this is quite rare,
+
-
    you should be aware of it.</p>
+
-
 
+
-
<li><p>The file descriptors stdout, stdin and stderr referring to standard
+
-
    streams are declared differently in SharedCLibrary and UnixLib
+
-
    headers.  This is responsible for the mysterious missing symbol
+
-
    &quot;__iob&quot; sometimes seen at link.</p>
+
-
 
+
-
<li><p>Compilers may define some maths operations in terms of differently
+
-
    named functions - in particular, division - so that even if object
+
-
    files are compiled against the C library, you may see link errors
+
-
    if you mix output from two different compilers.</p>
+
-
 
+
-
</ul>
+
-
 
+
-
This is not to say that mixing output is not impossible - it is, with
+
-
care, but you should take note of the differences.
+
 +
Some of the issues are discussed in the section on [[UnixLib#Differences|UnixLib Differences]].
{{GCC and GCCSDK pages}}
{{GCC and GCCSDK pages}}

Revision as of 20:09, 7 December 2009

The workings of C with RISC OS and its interactions with various libraries often raise many questions. All too often these questions are incompletely answered, leading to more questions or confusion. This document attempts for the first time to fully explain all the concepts in an understandable way.

Contents

Standards

C is defined by a number of standards. Probably the most important one is the ANSI C standard. Among other things, this defines what functionality must be present in a standard C library implementation. When the "Shared C Library" is referred to on RISC OS we are talking about the library developed by Acorn which is ANSI compliant.

The Shared C Library (SCL) resides in a module in ROM (or RAM if it's softloaded) and is called by C programs linked to it via "stubs" (see below). It also provides other functionality required by a C program such as stack extension and general environment interaction.

POSIX is another standard which defines a considerable number of behaviour characteristics of Unix operating systems. Since these are invariably C-based, it also defines many C functions that should be provided by a POSIX-compliant system.

The SCL makes no attempt to implement any functions beyond those defined by ANSI - indeed it was never intended that it should - but UnixLib does implement many of these, along with all the functions found in the SCL. Because of this, UnixLib can be invaluable when making Unix programs work on RISC OS

While it is certain that UnixLib doesn't conform fully to POSIX, it makes a good effort, and it is being improved all the time.

Programs and Libraries

When a program is linked (the final stage where the executable is produced), the program will be linked to one of two things - SCL stubs, or UnixLib.

Stubs are a small piece of code that is accessed by your program when making a function call to a C function in the SCL occurs for the first time. Stubs "fix up" the call, and point it directly at the appropriate code in the SharedCLibrary module. The advantage of this is that the code is shared by all callers, and not duplicated for all programs. It also means that when a bug fix occurs, all programs benefit.

On the other hand, when a program is linked to UnixLib, all the library code used by a program from Unixlib is attached to your program. This explains why UnixLib programs end up bigger than ones linked with SCL. This is referred to as statically linked. There is one exception to this. UnixLib relies on the module SharedUnixLibrary. This module implements a small amount of functionality that cannot safely be put into an application. It is hoped that one day more functionality will move into this module to give the same advantages that the SCL module does.

Compilers and Libraries

By default, Norcroft uses the SharedCLibrary, and GCC uses UnixLib.

LCC also uses SharedCLibrary by default.

In some cases, it's appropriate that the compiler use the alternative library. As with all libraries, these are split into the library's headers which advertise their functionality, and the library itself, which contains the code. The following describes use of each library with the 3 compilers

  • GCC

    Inside the !gcc application are contained headers and library files for both UnixLib and SharedCLibrary. The latter is a free version which is functionally identical to the version supplied with Norcroft (with a few additions).

    Normal invocation will use Unixlib:

    gcc hello.c -o hello

    Use the -mlibscl switch to use SCL:

    gcc -mlibscl hello.c -o hello
  • LCC

    LCC is supplied with the same SCL files as are supplied with GCC in order to make it a stand-alone compiler.

    Normal invocation will use SCL:

    lcc hello.c -o hello

    Use the -Bunix switch to use UnixLib:

    lcc -Bunix hello.c -o hello

    This assumes that UnixLib is actually available. Currrently, UnixLib is only distributed as part of the !gcc application (in the past it wasn't). There are plans to make a stand-alone version for LCC and Norcroft. For more details, see LCC's !Help file.

  • Norcroft

    Norcroft is supplied with SharedCLibrary files.

    Normal invocation will use SCL:

    cc hello.c -o hello

    To use UnixLib:

    cc -jUnix: -IUnix: hello.c -o hello

    As for lcc, this assumes the presence of UnixLib. The comments in LCC's !Help file apply equally in this case.

In bigger programs, compiling and linking is usually split into two operations. You should ensure that you use the same flags at each point, otherwise you will have unexpected results.

Mixing Libraries and Compilers

It is possible to mix SCL and UnixLib-targeted AOF object files, but considerable care should be taken. In general, it is discouraged, and rarely required. Under GCC 4 it is not possible, since GCC 4 produces ELF object files instead, and these are soft-float rather than the traditional RISC OS hard-float.

Some of the issues are discussed in the section on UnixLib Differences.

GCC and GCCSDK pages
GCC under RISC OS

GCC for RISC OS, GCC tutorial, GCC common switches, GCC for beginners, UnixLib, ELFLoader
GCCSDK and Unix porting
GCCSDK, GCCSDK Releases, GCCSDK Development, Using GCCSDK, Autobuilder Development and Packaging Cygwin setup, Accelerating autobuilder with apt-proxy, ChoX11, Developer help wanted

Personal tools