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

[Jack Twilley <jmt at twilley dot org>]

Kai Ruottu wrote:
> 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....

./configure --with-newlib --disable-shared --target=xscale-elf 
--enable-language=c,c++

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

Yes, but isn't all that part of binutils?  Or am I confused?  Reading 
further...

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

Okay, I constructed the directory and symlink as you suggested, and 
rebuilt.  I then had to add --disable-libssp, which got me very close. 
It failed while building "libobjc" (why is it doing that?  I said C and 
C++, not ObjC) with an inability to find tconfig.h.

/home/jmt/svn/gcc/libobjc/archive.c:27:21: error: tconfig.h: No such 
file or directory

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

Okay, then I did good there.

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

I have a target board, and in fact, a complete software suite that is 
tested on the target board.  Just need to get this GCC to work.

Jack.