Ian Lance Taylor wrote:
"Kevin Yohe" <kevin@xxxxxxxxxx> writes:
I am trying to configure and build a cross-compiler for a powerpc-750-elf.
I use the following parameters to configure it;
../gcc-4.1.0/configure --target=powerpc-750-elf --prefix=C:/gnu/usr
--exec-prefix=C:/gnu/usr/powerpc --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --with-newlib -v 2>&1 | tee config.out
The compiler works fine, however libc.a never gets generated. I noticed the
-Dinhibit_libc flag during the build. I am wondering how it got there, and
what parameters I need to use to generate libc.a? I thought that all I
needed was --with-newlib.
gcc does not include a C library. You can build it with newlib, but
you also need to download newlib and put it in your source tree.
In a from-scratch case this method can be suitable but generally the
'--with-newlib' should cause the
configures in those extra libraries (libiberty, libstdc++-v3) to provide
answers to what newlib has and
hasn't, so building these parts of GCC without any existing pre-made
C-library should always
succeed! Only the generic target headers, copied from
'newlib/libc/include' in the newlib-x.y.z sources
onto their final place (later overwritten by the final possibly somehow
modified target-specific headers),
should be available. (Building the extra libraries in GCC shouldn't
require those modified headers,
only the generic newlib headers). So the from-scratch build should also
succeed with the bare generic
newlib headers in the '$prefix/$target/include'! "Should" is the word
but unfortunately there has been
that stupid bug or "feature" a'la MS which requires the target headers
being seen also in the "system-
specific headers" directory, '$prefix/$target/sys-include', during the
GCC build :-( Since 1995 I think...
The newlib build&install will put the final, possibly target specific,
headers into the '.../include' but the
'.../sys-include' will be searched before that when using the installed
GCC, so there shouldn't be any
wrong 'generic' headers then... A really stupid "feature" without
any sanity :-(
Generally building the C library is a totally separate thing, one only
needs some GCC to do that... For
instance in this (possibly weird) 'powerpc-750-elf' case one could need
GCCs from 3.3.6 to 4.2.0 to
this same $target. Which one then being used to compile the 'newlib' ?
Or put every GCC to use its
own C library built by the GCC in question? The traditional way is to
build the C library and then test
it thoroughly and after that to use the trusted C library with all the
later built GCCs. Maybe some day
checking whether some of the newer GCCs could produce a better result...
I would suggest learning to build the components: binutils, GCC, C
library, GDB (with the PowerPC
simulator) separately, one at a time and so also updating them
separately later. Doing otherwise is
like getting a new bicycle when one of the tyres gets a hole! (I myself
did this with an 10 or so old
russian-made bicycle, after fixing it too many times. The german-made
bicycle which replaced it has
now served me over 20 years with not so many fixes... It costed 5 times
more than the russian one
so it should serve me still the next 30 years. So sometimes starting
from scratch again has its own
sanity :-)
The 'powerpc-750-elf' target name sounds "weird" because :
- the 'powerpc-elf' has been an alias for the never sold
'powerpc-sysv4' (for instance "Solaris 2 for PPC")
- the PPC750 may be one the 'SPE' models and so the 'powerpc-*spe',
for instance 'powerpc-eabispe'
could be what one could want instead of this $target....
But people should know what they are doing, so without knowing more it
is hard to say what the goal
with the 'powerpc-750-elf' target is...
