Working ELF GCC

Nick Burrett nick at dsvr.net
Mon Oct 6 02:51:13 PDT 2003


Peter Naulls wrote:
> In message <3F813656.4000602 at dsvr.net>
>           Nick Burrett <nick at dsvr.net> 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 going to commit any of these changes to the GCCSDK tree ?
> 
> 
> Probably not until after the SE Show on the 18th.  In the mean time I
> wanted to gather comments on what is a somewhat radical change, and
> address any concerns before we make a mess, and gauge the reaction from
> the wider RISC OS community.
> 
> In particular:
> 
> How to work in binutils with GCCSDK.  I don't really want to import the
> source into the GCCSDK, and hopefully this can be built separately
> sensibly first.

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.

The source tree download considerations are not a concern -- you'd need 
to download it all to get it built anyway.

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

-- 
Nick Burrett
Network Engineer, Designer Servers Ltd.   http://www.dsvr.co.uk





More information about the gcc mailing list