bare metal with C++ support?

[Allen Curtis]

>> Using the sample configuration, such as armeb-unknown-eabi, does not
>> build g++. When you go into menuconfig, you are not given the option
>> to build any language other than C when you select bare-metal. I do
>> not see how this could just work....
>
> Using 1.3.1, he? Try svn trunk, that's supported. Please also note  
> that
> this is marked "EXPERIMENTAL".
>

I have svn trunk but yes, I was using 1.3.1. Any changes I would make  
would be against the svn tree.

> Also note that those bare-metal toolchains are /truly/ bare-metal, in
> that there will be *no* C library at all in the toolchain, not even  
> newlib.
>
> From my understanding, a bare-metal compiler/toolchain is the strict
> minimum to compile, build and assemble source code. You are then on  
> your
> own to provide "system support libraries".
>

Ok, but there is a need for a compiler for OS-less embedded systems.  
In that case you may want standard library support such as newlib or  
some other library. My lack of understanding of the GNU C++  
implementation which makes me doubt whether you can have the C++  
language without some sort of library support. At least that was my  
suspicion when I did not see C++ as a selectable option.  :)

> For example, a bootloader does not need a C library to build (APEX at
> least doesn't); the kernel should be buildable by a bare-metal  
> compiler,
> alas there's ACPI stuff that relies on the compiler setting some  
> defines
> that are available only on target tuples like *-*-linux-* (or so is my
> understanding of the issue). I managed to build a workable ARM Linux  
> 2.6.26
> (or was it .25?) with such a truly bare-metal toolchain, but without  
> ACPI.
> Maybe I should poke the ACPI people about the issue...

Very true, you can have a "bootstrap" compiler (bare-metal if you  
prefer) and compile Linux, U-Boot and other non-OS based applications.  
This is one of the main reasons why you can have different compiler  
versions for applications vs. kernel development.

Thanks,
Allen


--
For unsubscribe information see http://sourceware.org/lists.html#faq