Working ELF GCC

Peter Naulls peter at
Tue Oct 7 03:13:26 PDT 2003

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.
> On the second point, I don't see why it should be necessary for tools to
> support *both* formats. There are tools available for each format; presumably
> people can use the tool most suitable for their purpose. A long term aim may
> be to make more universal tools.

Precisely because of the point you're trying to make here, and the
point I stressed on drobe comments.  We must make any transistion as
smooth as possible.  Having a sets of tools that don't particularly
work together, or which produce objects which even though entirely
compatible at the code level, which can't be used together is going to
cause major disruption.

> > 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
> > this.
> > 
> Yes, that's true. However, I don't feel I should be in the business of
> telling people to go and get (at some undetermined cost) another linker to
> replace the one they have been quite happy with, just so that I can build
> OSLib faster. Similarly, I don't feel I should be telling people to get - and
> build - gccsdk, in order for them to use lk to link with OSLib.

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.

> My feeling is, and please don't take this to be in any way antagonistic, that
> I would not be able to build OSLib using GCCSDK if that meant I could *only*
> supply it in ELF format. 
> I also believe that you would be similarly limiting the scope of UNIXLib if
> that were only available in ELF.

I don't think that's been implied.  We would only want to do this if
there was a way of easily using ELF and ALF together.

> > 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?

See above.  Don't presume that I'm dictating what should be done; only
what *can* be done *right now*.   I'm after pracitcal suggestions about
what should be done.

> > 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'm having a problem getting a consistent opinion from you.  Above you
says you don't see that tools should support both formats, but here you
say they should do.  I'm not advocating making any tool "fit" - as
always, we should use what is most appropriate.

> > 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.
> > 
> Yes, that is so. Even you acknowledge the problem with this statement by
> quoting "simply". There will be cases, not many, but they will be killers,
> where this is not possible, for instance where sources are not available for
> this simple task.

I acknowledge lots of problems, otherwise I would not have written this
at all.  I _do_ find this a little antagonistic.

> > 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.

> 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.
> I'm not rejecting your proposals, but advocating a more softly, softly
> approach.

As I say, I'm lacking both practical solutions to the problems at hand,
and a consistent picture from you.

Yes, we _should_ make it as painless as possible.  To do this means
having some of the tools support both formats so that this is the case.

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

More information about the gcc mailing list