This is the mail archive of the mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [crosstool-NG] Design discussion

On Sat, Apr 11, 2009 at 1:13 AM, Rob Landley <> wrote:
> On Friday 10 April 2009 23:14:33 Thomas Charron wrote:
>> ? And those of us who are caring about bare metal?
> I've used a jtag to install a bootloader and linux kernel on bare metal, so
> presumably you mean you want to build something other than linux system to
> install on that bare metal? ?(Such as building busybox against
> newlib/libgloss?)

  I'm talking about bare metal.  Typically, these systems have no more
RAM then is present on the processor.  Like, 64k.  There is no
bootloader, no busybox, and most specifically, no OS.

> How does this differ from building a very complicated bootloader, or linking
> against a different C library? ?(If you're building a complete new system on
> the bare metal, do you particularly care about binutils or gcc versions other
> than "fairly recent"?)

  Yes.  Since GCC is generally tested on 'real' systems, some versions
perform different then others depending on the target processor
itself.  In some cases, occasionally a version of GCC simply won't
work at all for a given processor.

>> ? There is no single toolchain. ?That's an assumption that works for
>> *your* environment.
> Could be, but I still don't understand why. ?Care to explain?

  See above.  bare metal *ISN"T* running Linux on a small box.  It's
another beast entirely.

> I've built many different strange things with generic-ish toolchains, and
> other than libgcc* being evil without --disable-shared, swapping out the
> built-in libraries and headers after the toolchain is built is fairly
> straightforward (for C anyway). ?You can do it as a wrapper even.
> (I suppose you could be referring to languages other than C? ?C++ is a bit
> more complicated, but then it always is. ?Java is its own little world, but
> they put a lot of effort into portability. ?Haven't poked at Fortran since
> the 90's.)

  Specifically, I've been working with a mashed in version of newlib,
and newlib-lpc.  In those cases, you actually don't use the GNU C
library at all.  Additionally, you can use newlib and gcc to compile
C++ applications (however, no STL, etc support).  I also have a small
side project to try to move the uclibc++ libraries to bare metal.

-- Thomas

For unsubscribe information see

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