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.
