Re: AIX Host -> PowerPC Linux

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Kevin Heatwole wrote:
> 
> I was unaware of the "-print-search-dirs" option on gcc.  It wasn't
> listed in the man page on gcc (that I have installed).
>
> Can you or someone explain a little more how gcc finds the include directory?
> 
> Is there a similar default search path for includes?
> 
> In other words, when resolving "#include <stdio.h>", where does the
> gcc cross compiler look?

 I haven't looked the Gatliff's FAQ, but would assume the following facts
appearing there first:

 - A cross-compiler uses the $prefix/$target as the root for the target
   stuff. The subdirs 'bin', 'include' and 'lib' have the binutils, target
   headers and target libraries.

 - All the available target stuff must be preinstalled there before starting
   to build GCC. This enables the build to succeed although only the target
   name would be given to 'configure' (using the '/usr/local' default for
   $prefix).

 - The $prefix and $target are the values given as '--prefix=$prefix' and
   '--target=$target' when configuring binutils and GCC. If the '--prefix='
   is not used, the default '/usr/local' will be used in installation.

 The search-order for the headers will be handled later, but it is the C
preprocessor which does the search. And a './cpp -v' (earlier) or './cpp0 -v'
(now) will show the search paths for the preprocessor...

> I see $prefix/include and $prefix/$target/include (the later is where
> I copied the /usr/include from the target machine - maybe this should
> have been $prefix/$target/sys-include).

 You have them in the right places, if following the GCC manual. The use
of the 'sys-include' is a serious bug in the current GCC sources --- only
the files seen there will be handled by the 'fixincludes' now.

 Although the GCC manual clearly says (in the definition of the
GCC_INCLUDE_DIR and in many other places) that the GCC build will search
the target headers from '$prefix/$target/include', and will try to fix them
for GCC during the build (if necessary), someone of the GCC-developers
somehow misunderstood the meaning of the 'SYSTEM_INCLUDE_DIR' and thought
that people are now using the 'sys-include' (expecting the GCC-developers
to know something about cross-compilers may be vain?) and changed the search
dir for 'fixincludes' into the 'sys-include' sometimes in 1995...

 Or something like that, perhaps we will never hear the reason... The sad
fact is that instead of continuing to report this as a serious bug, people
are going to take it as a 'feature' which cannot ever be fixed, just as
they are used to behave with Microsoft. If FSF is now just like MS in this
respect, what can we expect from the "open software"... The 'sys-include'
even ghosts in the official 'www.gnu.org' docs, so there are people who
still believe all cross-compilers having the target headers being installed
into '$prefix/$target/sys-include'. It would be fair to arrange a voting...
But if a native compiler searches the standard headers last, why a cross-
compiler should search them second last?  

 Ok, the sources are there and anybody can fix the 'sys-include'-bug away.
I did this and have attached the patch for the main 'Makefile.in' here.
The 'gcc/cross-make' fixing can be left as homework... Unfortunately the
bug remains in the official GCC sources if nobody lets it be fixed...

 The glibc-headers shouldn't be fixed. I looked at what the 'fixinc' did
and found out that some Linux kernel headers were fixed and installed into
the GCC_INCLUDE_DIR. As you should know, the '/usr/include/asm' and the
'/usr/include/linux' are symlinks to the current Linux kernel sources in
the native installation. I haven't seen a suggestion about where to put
the Linux kernel sources in a cross-installation, but perhaps the
'$prefix/linux' would be ok... What you got as the 'include/asm' and
'include/linux' when you "copied the Linux headers", is one thing for you
to solve, but anyway you may need to build Linux-kernels in the cross-
environment and may change their sources... So the GCC-installation having
some old fixed kernel-headers which will be found before the right new ones,
is absolutely wrong...

 The problem is with the 'limits.h'. If the GCC-build doesn't 'see' it
during the build, the one in the 'GCC_INCLUDE_DIR' will not '#include'
the 'syslimits.h' there and this will not #include_next' the 'limits.h'
from the glibc-headers...

 The workaround is to preinstall the target headers into
'$prefix/$target/include' and then symlinking the '$prefix/$target/sys-include'
into it. Then after the build to remove the symlink and check the 'fixed'
headers in the 'gcc/include', removing the subdirs 'gcc/include/asm' and
'gcc/include/linux' (after comparing the files there using 'diff' with the
originals and seeing that changing a '#ifdef linux' into a '#ifdef __linux__'
etc. were the only fixes done and these being unnecessary...).

 Or if fixing the 'Makefile.in' and 'gcc/cross-make', the symlink between
'include' and 'sys-include' isn't necessary, but cleaning the 'gcc/include'
from the 'fixed' Linux-kernel headers really is...
 
> Is the include directory hard coded using the --with-headers (a quick
> look at the configure script seems to put these in sys-include)?  If
> so, then is $prefix/include or $prefix/$target/include searched at
> all when doing a cross compile with no other options specified.

 The main reason to use the '--with-headers=' seems to be the ignorance
about the '$prefix/$target' as the place for the target stuff. And using
it votes for maintaining the GCC bug for all the new GCC-builders... It
is really hard to believe that using the 'cp' command is so hard that
avoiding it is recommended... 

 A cross-compiler searches the headers now from three directories:

 1. The first is the mentioned GCC_INCLUDE_DIR, the :
      $prefix/lib/gcc-lib/$target/$version/include

 2. The second in the search order is the CROSS_INCLUDE_DIR, the equivalent
    to the SYSTEM_INCLUDE_DIR for a native compiler, the:
      $prefix/$target/sys-include

 3. The third is the TOOL_INCLUDE_DIR, the equivalent to the
    STANDARD_INCLUDE_DIR (/usr/include) for a native compiler, the:
      $prefix/$target/include

 As earlier written, the 'cpp -v' or 'cpp0 -v' shows the search order...
(But hangs and needs a Ctrl-C...)

 The original aim for the SYSTEM_INCLUDE_DIR or CROSS_INCLUDE_DIR was to
keep the 3rd party headers which may replace or add-to/complete the standard
C headers for the target. The embedded target tools could keep the chip-
specific headers (defining the I/O-addresses, ISR-vectors, bit positions,...)
etc. there --- newlib doesn't include any of these, but the Cygnus BSP does...

 As seen the '$prefix/include' isn't there at all... If you have browsed the
archive of this maillist, I have suggested that it could be enabled for a
cross-compiler too, and the use would be to keep the common headers for all
GCCs in the system. The tcl/tk-headers is one example. A native compiler
searches this 'LOCAL_INCLUDE_DIR' before the 'GCC_INCLUDE_DIR'. In the same
way the CROSS_INCLUDE_DIR could be enabled for a native compiler too. Some
systems like the Win32-ones (Mingw & Cygwin) could keep the standard C headers
and the Win32-API headers separated in these two directories.

Cheers, Kai
*** Makefile.in.orig	Tue May 15 14:28:00 2001
--- Makefile.in	Tue May 15 21:01:33 2001
***************
*** 264,270 ****
  SPLAY_TREE_H= $(srcdir)/../include/splay-tree.h
  
  # Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
! CROSS_SYSTEM_HEADER_DIR = $(tooldir)/sys-include
  
  # Control whether to run fixproto and fixincludes.
  STMP_FIXPROTO = stmp-fixproto
--- 264,270 ----
  SPLAY_TREE_H= $(srcdir)/../include/splay-tree.h
  
  # Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
! CROSS_SYSTEM_HEADER_DIR = $(tooldir)/include
  
  # Control whether to run fixproto and fixincludes.
  STMP_FIXPROTO = stmp-fixproto
***************
*** 2185,2192 ****
  # exists.
  # We deliberately use tooldir instead of gcc_tooldir here.  gcc_tooldir
  # won't work because libsubdir doesn't exist yet.
! 	if [ "$(SYSTEM_HEADER_DIR)" = "$(tooldir)/sys-include" ] \
! 	   && [ -d $(tooldir)/sys-include ]; then \
  	  if [ -d $(libdir) ] ; then true ; else mkdir $(libdir) ; fi; \
  	  if [ -d $(libdir)/gcc-lib ] ; then true ; else mkdir $(libdir)/gcc-lib; fi; \
  	  if [ -d $(libdir)/gcc-lib/$(target_alias) ] ; then true ; else mkdir $(libdir)/gcc-lib/$(target_alias) ; fi; \
--- 2185,2192 ----
  # exists.
  # We deliberately use tooldir instead of gcc_tooldir here.  gcc_tooldir
  # won't work because libsubdir doesn't exist yet.
! 	if [ "$(SYSTEM_HEADER_DIR)" = "$(tooldir)/include" ] \
! 	   && [ -d $(tooldir)/include ]; then \
  	  if [ -d $(libdir) ] ; then true ; else mkdir $(libdir) ; fi; \
  	  if [ -d $(libdir)/gcc-lib ] ; then true ; else mkdir $(libdir)/gcc-lib; fi; \
  	  if [ -d $(libdir)/gcc-lib/$(target_alias) ] ; then true ; else mkdir $(libdir)/gcc-lib/$(target_alias) ; fi; \


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