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: [ECOS] Re: GCC: different OS targets.

Jonathan Larmour wrote:

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

> 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,
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]