Re: -Dinhibit_libc

[Kai Ruottu <karuottu at mbnet dot fi>]

Ian Lance Taylor wrote:
> "Kevin Yohe" <kevin@ssc-nh.com> 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...