Working ELF GCC

Peter Naulls peter at
Mon Oct 6 01:41:24 PDT 2003

In message <039b0b3d4c.Tony at>
          Tony van der Hoff <tony at> wrote:

> On 5 Oct 2003, in message <2225c03c4c.peter at>,
> Peter Naulls <peter at> wrote:

> > If nothing else, it will avoid the current problems with the linker in
> > current CVS that cause compiles to fail, and misc other linker issues
> > that we've had recently.
> > 
> > Comments?
> > 
> Are you suggesting that in the future ALF will no longer be supported?

This is just the sort of issue I would like discussed, so that everyone
is aware of the issues.

> This would be a problem for those, who like me, build link libraries (i.e.
> OSLib) under Linux, but with the intention that it will be linked under RISC
> OS, together with ALF objects, using some undefined linker.
> I'm probably worrying unduly, as the same argument would apply to UnixLib.
> However, in that case, I've lost the plot somewhere. What precisely, if any,
> is the impact of this proposal?

I'll see if I can outline everything along with possible solutions.

Continuing to support AOF/ALF if at all possible is desirable for
plenty of obvious practical reasons.  At the same time, the number of
tools that support Acorn formats and ELF together is pretty limited.

In the case of OSLib, one possibilty is to indeed compile to ELF (and
unix archive) under Linux - 'link' can handle this format if you have a
recent version of Acorn C/C++ tools, and of course binutils 'ld' uses

The UnixLib I've put in the ELF GCC is indeed ELF - again, the same
thing applies - you could use 'link' with Norcroft to link this against
any AOF objects in RISC OS - and output an AIF or ELF binary.

Ideally, we would have ld able to handle AOF/ALF, but this is complex as
has been pointed out.

To work with the ELF toolchain, existing AOF/ALF stuff can "simply" be
recompiled - this is a lot less painful than the 26bit -> 32bit
conversion.  GCC will now expect GNU format assembler, although we
should soon have a version of 'as' that is able to output ELF too, to
support ARM format - rewriting assembler; even with the script I put
together isn't much fun, and lots of hassle we don't need.

Library files will now become .a instead of the previous .o (although
our ld did support '-lmylib' for ALF files ending in .a)

There are a number of changes I've effected to the build of GCCSDK,
which deserve separate attention, and I'll discuss in another thread in
due course.

Peter Naulls - peter at        |
AcornSearch -  | Relevant RISC OS searches

More information about the gcc mailing list