Re: --with-headers=$GNUTOOLS/$TARGET/include when configuring gcc,why use this?

["Kai Ruottu" <karuottu at mbnet dot fi>]

"Liuzhao" <liuzhao99@mails.tsinghua.edu.cn> wrote:

>  Can anyone tell me the function of --with-headers=$GNUTOOLS/$TARGET/include
>  when configuring gcc? I see some papers use it ,while some others donnot use this option.  

 It causes the target headers normally installed into the $prefix/$target/include (your $GNUTOOLS/...)
to be duplicated into the $prefix/$target/sys-include, where the GCC build then tries to find them
when examining whether they should be fixed for GCC or whether some headers do exist...

 In a native build the headers in '/usr/include' stay there, they must no be pointed with any wacky
option and be copied elsewhere, where they are installed, is enough.  The same option would be
required there too and the headers in '/usr/include' being copied into '/usr/sys-include' or otherwise
they wouldn't be found...

 If you will see some sanity in the current practice after knowing this, please tell me too!  Even the
latest GCC release (3.3.2) manual ("GCC Internals") tells :

  14 Standard Header File Directories

  GCC_INCLUDE_DIR means the same thing for native and cross. It is where GCC stores its
  private include files, and also where GCC stores the fixed include files. A cross compiled
  GCC runs fixincludes on the header files in `$(tooldir)/include'.

and so on.  So what the GCC build now does, clashes badly with the GCC documents, they
clearly tell that the '$(tooldir)/include', ie. the '$prefix/$target/include' will be examined and no
header copying and duplicating is necessary...

 If being paranoid, one could think the current practice being some kind of torture, the GCC
developers hating all the cross-GCC builders for some peculiar reason...

 It is quite optimistic to expect the 'fixinc' stuff handling all those hundreds or thousands targets
and their different versions always perfectly, so the first thought about this mess is that it has
been left to the GCC builder to decide whether one lets the GCC build to try the fixing. The fact
is that some target headers must be seen in the $prefix/$target/sys-include, and currently they
seem to be the 'stdio.h', 'stdlib.h', 'limits.h' and 'unistd.h'. Otherwise the GCC build uses its own
dummy stubs with minimal information in them, which isn't enough or is wrong...  On a Unix-like
system one can symlink these there, but on Windoze etc. they must be duplicated.

 If Linux is the target, it should be safe to symlink everything in 'include' into the 'sys-include'.
The glibc-2.2.5 for instance has the name '__thread' being used in protos in its headers when
the newer GCC 3.x sources use this as a type... So the '__thread' must be fixed to be '__thr'
or something which doesn't clash with the earlier defined type...

 Generally one should think that is fixing the stuff in '/usr/include' during the native build succeeds,
fixing the same headers in a cross build should succeed too...  But it is totally unknown whether
those GCCs for 'h8300-elf', 'sh-elf', 'mips-elf', 'arm-elf' would succeed in their native build. I would
claim that only the aes sedais from the brown ajah could have this information (see: "The Wheel
of Time"), since the world was broken all the information about these native elves has disappeared;-)

 So unfortunately a GCC builder should know something about what happens when the GCC will
be built, just as a car driver must know what can happen when the motor is started and a gear
is in... All kind of precautions must be done like checking whether there are any small children
hiding below the car in the latter case, but although starting the GCC-build isn't that serious, one
should still know something about what will happen after writing the 'make'...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com