Working ELF GCC

Tony van der Hoff tony at mk-net.demon.co.uk
Tue Oct 7 02:44:00 PDT 2003


On 6 Oct 2003, in message <98180e3d4c.peter at chocky.org>,
Peter Naulls <peter at chocky.org> wrote:

> In message <039b0b3d4c.Tony at tonyv.gotadsl.co.uk>
>           Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> 
> > On 5 Oct 2003, in message <2225c03c4c.peter at chocky.org>,
> > Peter Naulls <peter at chocky.org> 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.

Well, I had hoped not to be a voice in the wilderness, and to see other
people's contributions. So far, it seems I'm alone in being concerned about
this, so maybe I'm missing something.

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

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

I have enough queries from users who don't understand the link process,
without introducing another major variable.

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.

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

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

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

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

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

I hope this helps...

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
Buckinghamshire, England  | http:www.mk-net.demon.co.uk




More information about the gcc mailing list