How do I build C++ for xscale-elf?

Kai Ruottu
Thu Sep 28 09:05:00 GMT 2006

Jack Twilley wrote:
> I tried gcc-4.1.1 from SVN (gcc_4_1_1_release) with the following 
> configure line:
 ???  No configure line seen here....
> It fails on compiling regex.c in xscale-elf/libiberty with a whole 
> bunch of errors about not bein able to find sys/types.h and strings.h 
> and the like.
 These are in the target C library, in its headers...  Although using 
the '--with-newlib' should remove the need to have the target libraries and
startups (the binary parts) preinstalled, the need for the target 
headers (the text parts) is still there :-(   Besides them being needed 
in compiling
the extra target libraries, the GCC build tries to "fix" them and 
investigates the existence of some headers like 'limits.h' among them....

  The newlib-sources have the "target headers" in a easily copyable 
place: for instance in 'newlib-1.14.0/newlib/libc/include' in the current
'newlib-1.14.0' sources.  So just install them into your chosen 
'$prefix/xscale-elf/include' and because of the famous 'sys-include 
bug', add
a symlink to put the '$prefix/xscale-elf/sys-include' to point to the 
'$prefix/xscale-elf/include', so that the GCC build sees the same headers
also there...  The 'sys-inlude' is the equivalent to the optional 
SYSTEM_INCLUDE_DIR in the native incarnation of a GCC for something,
the 'include' is the equivalent to the STANDARD_INCLUDE_DIR, usually 
'/usr/include' in the native twin...  But the GCC developers have
somehow mixed these two and when meaning the 'standard headers' they use 
the name 'system headers'.  So just talking and writing about
system headers seems to make the unexisting into existing and this way 
trying to give some sanity into this "sys-include mess" :-(   The
existance check will be done in the 'sys-include', not in 'include', 
whatever the GCC manuals claim about this...

 > I have installed binutils-2.17 from SVN (binutils-2_17) for 
xscale-elf.  Its version of libiberty installed into /usr/local/lib/ 
which makes me wonder
 > how many things I accidentally overwrote while building that, but 
I'll rebuild FreeBSD later.

 Installing the 'libiberty.a' for the $host really seems to be vain and 
also wrong.  Functions from it may be linked into the produced binutils
binaries but expecting it being missing from the host system or that the 
existing 'libiberty.a' would be older, can be wrong.  For some reason
some very old binutils may be built for some target and then some very 
old 'libiberty.a' replacing the existing one...  Another "feature" a'la MS
just like that "sys-include" one?

 > Should I have not built binutils?

 If you already had 'xscale-elf' targeted binutils with some older GCC 
for this target when starting, then reproducing the target binutils would be
vain, "don't fix it if it ain't broken" is the old rule...  If you 
hadn't them, then building them was motivated.

 >   Was there something else I missed?

 After the GCC you of course should build the C library if it is 
missing.  And if you want to debug/simulate the XScale executables on 
your FreeBSD
host, then building also the GNU debugger with its ARM-simulator, can be 
motivated...  Everyone without any target board maybe wants to run the
first produced "Hello World" somewhere.

More information about the Gcc-help mailing list