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] |
Jonathan Larmour wrote: > 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. I would be (I think). Surely this code would be part of gcc. If it is bleeding edge then the use of gcc snapshots or patches would work. > 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. It would be nice to have just one compiler but I think I could live with having one compiler for each ABI, but having multiple compilers for the same ABI (eg EABI) seems wasteful. I would probably still push for the one compiler and be able to select the multilibs to build (specify each lib or family of libs via configure). > 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. Surely this is easily accomplised via the specs file (eg. -mecos). Brendan Simon. ------ 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] |