This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Roger Williams wrote: > > >>>>> Brendan Simon <brendan@dgs.monash.edu.au> writes: > > > I would like to be able to build gcc _ONCE_ for powerpc-eabi and > > be able to build the RTEMS, eCos (or any other OS) libraries and > > install them in an appropriate place. > > Yes indeed, this would be *very* helpful. I'm currently developing > MPC8xx code for no-OS, Linux, and Neutrino, and I have separate > development installations for each of these. I want to start working > with eCos, but I dread the thought of yet another set of powerpc-eabi > tools and libraries... You only need a standard powerpc-eabi toolchain for eCos, not a special one. The only constraint is that it must be post egcs-1.1.2. gcc-2.95.1 should work absolutely fine. As Bart Veer mentioned on ecos-discuss, things like thread-safe C++ exceptions require knowledge of the OS. However, to be honest, I think that's all there is. If you were not interested in thread-safe C++ exceptions - and many RTOS folks aren't - then in general I don't think there is any technical reason for different toolchain targets, apart from convenience. But this isn't just convenience for the OS developers, but also for the compiler developers. If you consolidated two similar toolchains into one, e.g. powerpc-eabi and powerpc-elf, then this suddenly means you have to build (at least) twice the number of multi-libs when building a completely generic set of tools, in order to support the two ABIs. If you look at the current powerpc-eabi compiler, you'll see that it already has 25 multi-libs, which means building versions of libgcc, newlib, libio, and libstdc++ 25 times, which is already painful and disk-intensive. I am hoping we will eventually be able to make some changes to gcc that will reduce it's dependency on the run-time side at gcc compile-time. But don't hold your breath :-/. BTW, for these reasons, making eCos use the standard toolchain isn't as clean as we would like. We override the linker script, and use -nostdlib to avoid picking up the default crt0's and libc. I don't know how easy it is for other OS's to do something similar though. Jifl -- Cygnus Solutions, 35 Cambridge Place, Cambridge, UK. Tel: +44 (1223) 728762 "I used to have an open mind but || Get yer free open source RTOS's here... my brains kept falling out." || http://sourceware.cygnus.com/ecos Help fight spam! http://spam.abuse.net/ These opinions are all my own fault ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |