Working ELF GCC

Peter Naulls peter at
Mon Oct 6 03:05:12 PDT 2003

In message <3F813B11.50300 at>
          Nick Burrett <nick at> wrote:

> The whole point behind the GCCSDK package is to contain *all* sources
> that are required to create the GCCSDK package.  Leaving certain 
> applications out just means we go back to the old development system 
> that I used to have.  Like I said before it is very difficult to 
> maintain the applications from different repositories and keep them in 
> sync.  By keeping the packages together, you guarantee that the 
> supporting applications and libraries are correct for *that* release of 
> the GCCSDK.

Fine; this is probably best.  Importing regular releases of binutils
into the tree shouldn't be a problem.  I need to have a play with
configure stuff to make sure binutils gets correctly driven by the top
level script. Ideally, I'd like to make as few changes to binutils as
possible - and have them fed back if we do.

> > All the library filenames will be come library.a or a/library.
> > unixlib.o will be some libunixlib.a (or a/libunixlib).
> This is not a concern.  The directory structure already has the target 
> triple i.e. arm-riscos-aof.  You're merely storing ELF stuff under 
> arm-riscos-elf.

This wasn't really my worry; it's just a heads up.  I could either
introduce a LIBEXT variable into the build, or just change the
filenames for both.  Having different filenames for ALF vs archive
formats has advantages and disadvantages.

Peter Naulls - peter at        |
Unix Programs on RISC OS               |

More information about the gcc mailing list