This is the mail archive of the 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]

Re: GCC: different OS targets.

Roger Williams wrote:
> >>>>> Brendan Simon <> 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

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.

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."    ||
Help fight spam!  These opinions are all my own fault

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]