Working ELF GCC

Nick Burrett nick at
Tue Oct 7 04:49:05 PDT 2003

Peter Naulls wrote:
> In message <d5a9973d4c.Tony at>
>           Tony van der Hoff <tony at> wrote:
>>>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.
>>Agreed on the first point; in fact I would have thought it more than
>>desirable; but rather vital. This is, after all, software for the RISC OS
>>platform we're talking about, and I believe backward comptibility, is one of
>>its strong points. Let's not abandon that on a crusade towards Linux.

I'm not entirely convinced that it is vital.  I will stress that we 
*will* maintain compatibility with AOF.  Or at least a toolset will 
exist for the purposes of working with AOF/ALF.

My original reasons for wanting ELF support were:

1. Debugging symbols.  Potential to use GDB.

2. PIC.

3. Weak symbols.  I don't think the AOF implementation is a true weak 
symbol implementation.  I have a feeling that C++ binaries will be 
smaller in ELF than AOF because of this.

I figured that we would make two GCC releases (or one large combined GCC 
release).  One with AOF support and one with ELF support.  People could 
choose the desired format.

Upon releasing it to the wild, the decision whether to make a GCC build 
that worked with both formats would be made by the end-users. 
Ultimately if we produced an ELF build and nobody wanted to use it, then 
there would be no point further developing it other than for personal 

> Fine, and I'm not suggesting you should.  What I _am_ doing is pointing
> out the current situtation.  What I'm lacking from your reply is
> practical solutions about what we should do.

Unfortunately I don't have any.

>>>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.
>>You *could* do, but why make life difficult for the users?

Yes, it certainly would.  I think I said in an earlier post that I don't 
think we're going to see the real issues until we actually start trying 
to interwork the two formats.

>>>Ideally, we would have ld able to handle AOF/ALF, but this is complex as
>>>has been pointed out.
>>That would ameliorate the situation, by making another linker available, but
>>it doesn't fix the underlying problem. 
> No? In this case, both the GCC linker and the Acorn linker now
> understand both formats, and interoperability is essentially invisible.
>>Forgive me if I'm wrong, but you seem to be saying that the move to ELF is
>>inevitable, and all we can do is try to make the RISC OS tools fit. Is this
>>actually the case? In my view, rather than the step-wise change that you are
>>suggesting, it would be preferable if the current tools could optionally
>>generate either AOF/AIF or ELF. That way developers could switch to the new
>>format as and when appropriate. I have no idea how much effort this would
>>require, nor even if it is feasible.

I don't think we are saying that the move to ELF is inevitable.  We 
might be able to demonstrate that the move to ELF is a compelling one if 
we can prove that the ELF userland tools allow developers to do stuff 
they couldn't easily do with AOF.

>>>Library files will now become .a instead of the previous .o (although
>>>our ld did support '-lmylib' for ALF files ending in .a)
>>Lots of makefiles will have to change...
> ...perhaps fewer than you think.  And we can always modify 'ld' to look
> for '.o' - that is hardly difficult.

I think any developer who decides to use the ELF toolchain as opposed to 
the AOF toolchain should think carefully about the consequences of such 
a change.

It is possible to write makefiles that could target both formats.  I 
think this is more of an issue for developers of libraries rather than 

>>Peter, I do hope I've misunderstood the arguments, but I'm deeply concerned
>>that this will introduce significant problems to users, especially the maybe
>>less technically adept, when we really ought to be encouraging them. Maybe
>>you feel, with some justification, that GCCSDK/UNIXLib is not aimed at those
>>users; I must say that OSLib makes no such distinction.

Many users seem to be frightened of using GCCSDK/UnixLib anyway.  I see 
no reason not to scare them further by providing a myriad of different 
target types :-)

Certainly writing some sort of information on the website that clearly 
explains this stuff in a way that makes users choose the right tools for 
the job would be a tricky task.

Nick Burrett
Network Engineer, Designer Servers Ltd.

More information about the gcc mailing list