crosscompiler x86->solaris2.8

Kai Ruottu kai.ruottu@luukku.com
Tue Apr 16 04:53:00 GMT 2002



Rupert Wood wrote:
> 
> Kai Ruottu wrote:
> 
> > > $prefix (=foo/myGCC). That works fine. Then I put the /usr/include
> > > tree from solaris into foo/myGCC/sparc-sun-solaris2.8/sys-include/
> >
> >  Please check what the aim for the '$prefix/$target/sys-include' is,
> > and what for the '$prefix/$target/include'...
> >
> >  RTFM, "Standard Header Directories"...
> 
> I think I'm the one responsible for giving him this advice. I concede
> didn't RTFM "System Header Directories". However, sys-include is *not*
> SYSTEM_INCLUDE_DIR; it is [CROSS_]SYSTEM_HEADER_DIR.
> 
> The "--with-headers" configure option copies the path specified to
> sys-include. This directory is processed by fixincludes at build time.
> This is all correctly documented in the manual.

 You mean the text starting with this in the "Using and Porting...." from
Stallman and other GCC-developers? (I understand the 'manual' meaning the
official '.texi'-files coming with the GCC-sources, not the 'opinions' from
single persons in some FAQs in the net...)

---------------------------- clip -------------------------------------
Standard Header File Directories

GCC_INCLUDE_DIR means the same thing for native and cross.  It is where
GNU CC stores its private include files, and also where GNU CC stores the
fixed include files.  A cross compiled GNU CC runs fixincludes on the
header files in $(tooldir)/include.  (If the cross compilation header files
need to be fixed, they must be installed before GNU CC is built.  If the
cross compilation header files are already suitable for ANSI C and GNU CC,
nothing special need be done).
---------------------------- clip -------------------------------------

 So what the current 'gcc/Makefile' now does, clashes with the 'manual'
and to understand this, one may have several theories:

 - in order to not spoil the 'already suitable' newlib and glibc headers,
   installed into '$(tooldir)/include' by their own 'make install', when
   built, they will now be 'hided' from the 'fixincludes' by putting it to
   search where nothing should be... "CROSS_INCLUDE_DIR is used only for
   a cross compiler. GNU CC doesn't install anything there."  This sounds
   sane, although for which purpose a cross-compiler would use it was left
   unknown... (My guess has been 'for system-specific', ie. for the 'local'
   purposes for which the 'LOCAL_INCLUDE_DIR' is aimed with the native-GCC).

 - someone didn't see the difference between 'system' and 'standard' and
   thought the '$(tooldir)/sys-include' really being the 'normal' and
   de-facto standard for installing the 'standard C headers' for the cross-
   target... And the same person invented the '--with-headers' and put it
   to copy the standard C-headers for the target into the 'sys-include'...

 More mess will cause the fact that the produced main Makefile and the
'gcc/Makefile' use the option '-I$(build_tooldir)/include' for searching
the target headers during the build... If the headers are in the
'$(tooldir)/sys-include', this doesn't work and is vain. Earlier the
'$prefix/lib/gcc-lib/$target/$gcc_version' wasn't created during the build
and this option was necessary, but then it pointed to the wrong place if
the aim was to start to use the 'sys-include', not the 'include'... Now it
is vain because both the 'include' and 'sys-include' will be found because
the '$prefix/lib/gcc-lib/$target/$gcc_version' will be pre-created during
the GCC-build...

 It is true that many targets still need their 'standard C-headers' being
fixed for GCC, but if one uses already fixed headers with an already installed
cross-compiler and these will again be fixed, the result is a mess. I also
wouldn't trust GCC 'fixing' the up-to-date glibc and newlib headers, these
should be 'already suitable'... With the Linux-targets I have seen GCC trying
to fix also the 'include/asm' and 'include/linux' and put them into the
GCC_INCLUDE_DIR... These just happened to be there during the build, symlinked
from the kernel sources then, but after the GCC-install the kernel sources may
be updated many times, and the symlinks in '$prefix/$target/include' updated
too, but all the time the old 'fixed' kernel headers will be used instead.
I have experimented with the headers-fixing sometimes...

 So 'hiding' the standard C-headers from 'fixincludes' during the GCC-build,
so never using the '--with-headers=' or preinstalling the target headers into
the '$prefix/$target/sys-include', but preinstalling them into the
'$prefix/$target/include', is my advice...

 BUT if one wants to experiment with the header-fixing, the results MUST be
checked and manually fixed to be sane...

 The 'limits.h' and 'math.h' in the Solaris2 case are well-known for needing
to be 'seen' and fixed (the 'struct exception' in 'math.h'), so these should
be seen in the 'sys-include' during the build.

 The situation with the placement of the target headers is a mess and quite
a lot must be done with standardizing it...

 "Become familiar with the target before trying to aim to it", would be a
good advice... In the Solaris2-case the "Solaris2-FAQ" is a must, and one
must have some kind of thought about where to put all the stuff which doesn't
exist in '/usr/include' and '/usr/lib' (or were these at '/usr/ccs/...'?),
like the X11-stuff, 'dt', 'openwin' etc.

> The compiled-in directory search order for cross-compilers looks a bit odd,
> though: that might need some attention and/or fixing.

 Just as the one for a native GCC, the gcc-3.x has already changed the
TOOL_INCLUDE_DIR to be after the GCC_INCLUDE_DIR. In gcc-2.95.x it still was
before it... I would add the LOCAL_INCLUDE_DIR also for cross-compilers and
add the CROSS_INCLUDE_DIR for native compilers, so the only difference between
a native and a cross-compiler would be that the native one still searches from
'/usr/include' after all the same directories present in a cross-compiler...
If one has tools for five Linux-targets (e.g. PPC, ARM, MIPS, x86_64, ia64)
and concentrates to a single kernel version at a time, having the kernel
headers in 'LOCAL_INCLUDE_DIR/linux' and 'LOCAL_INCLUDE_DIR/asm-*' would be
much better organized than having these splitted into separate places... A
single tcl/tk-version, GUI-toolkits etc. common for them all too...

 But if one would like the target-specific headers be included before the
'common' ones, the '$prefix/$target/*include' should be searched before the
LOCAL_INCLUDE_DIR... So I must agree with your "might need some attention
and/or fixing" and add the word "still"...

> I concede that I've gained more of my knowledge of cross toolchains from
> experimentation and reading the configure scripts rather than reading
> the manual. I'm welcome to correction or advice.

 My opinion is that the GCC-manual and what happens during the build shouldn't
clash this badly... The manual ('install.texi') and the sources are easy to
fix, we are talking about 'Open Software', not anything for which only a
preprinted manual and prebuilt binaries are available... Of course anyone
can fix these bugs and start distributing 'fixed' GNU-sources and 'fixed' GNU
manuals which are compatible with each others... But is this sane ?

 Reporting this clash between the GCC-manual and the GCC-sources hasn't yet
caused any actions from the GCC-developers... BTW, one earlier suggestion for
the manual in this issue follows:

---------------------------- clip -------------------------------------
Standard Header File Directories

GPLUSPLUS_INCLUDE_DIR means the same thing for native and cross.  It is where
the C preprocessor (earlier named as cpp, now cpp0) looks first for the standard
C++ header files.  The standard C++ library installs only target independent
header files into this directory.  The name of this directory will be different
with the versions of the standard C++ library, but generally it is a subdirectory
under the LOCAL_INCLUDE_DIR ($(local_prefix)/include).

LOCAL_INCLUDE_DIR means the same thing for native and cross.  GNU CC doesn't
install anything there.  It is where the C preprocessor (earlier named as cpp,
now cpp0) looks first for the C header files (and next with C++).  Only the
target independent C header files should be installed into this directory.  It
is normally set to be the $(local_prefix)/include.  Users can install their
target independent 3rd party header files (like tcl/tk, GUI-toolkits etc.) into
this directory.

GCC_INCLUDE_DIR means the same thing for native and cross.  It is where GNU CC
stores its private include files, and also where GNU CC stores the fixed include
files.  A GNU CC build as a cross compiler runs fixincludes on the header files
in $(tooldir)/include.  It does not matter if the target header files there need
to be fixed or not, they must anyway be installed there before the GNU CC build
is started.  There are also some header files like the limits.h whose existence
among the target header files will be checked and the private headers in GNU CC
will be modified accordingly.  If the target header files are already suitable
for ISO C and GNU CC, nothing special need to be done to fix them.  The
GCC_INCLUDE_DIR comes after the directory LOCAL_INCLUDE_DIR in the C headers
search order.

CROSS_INCLUDE_DIR means the same thing for native and cross.  GNU CC doesn't
install anything there.  It is where the C preprocessor (earlier named as cpp,
now cpp0) looks for the C header files after the GCC_INCLUDE_DIR.  Only the
target dependent C header files not belonging to the standard C headers for the
target (like the CPU- and I/O-ports describing headers from the chip-makers)
should be installed into this directory.  It is normally set to be the
$(tooldir)/sys-include.

STANDARD_INCLUDE_DIR is used only by native compilers.  When you build a native
compiler, fixincludes processes any header files in this directory.  It is where
the C preprocessor (earlier named as cpp, now cpp0) looks for the C header files
after the CROSS_INCLUDE_DIR.  It is normally set to be the /usr/include.

TOOL_INCLUDE_DIR is used only by cross compilers. For a cross-compiler, this is
the equivalent of /usr/include.  When you build a cross-compiler, fixincludes
processes any header files in this directory.  It is where the C preprocessor
(earlier named as cpp, now cpp0) looks for the C header files after the
CROSS_INCLUDE_DIR.  It is normally set to be the $(tooldir)/include.
---------------------------- clip -------------------------------------

 Currently enabling the TOOL_INCLUDE_DIR for a native compiler too, would be
my suggestion... This and STANDARD_INCLUDE_DIR being 'equivalents' or alternatives
told that they both couldn't be present, but when nowadays a native Linux-GCC
has this always empty, why then not in the future, until someone finds a suitable
use for it... Here is the 'cpp0'-output from a cross-GCC I recently built:

---------------------------- clip -------------------------------------
H:\usr\local\lib\gcc-lib\x86_64-linux-gnu\3.1>cpp0 -lang-c++ -v
GNU CPP version 3.1 20020408 (prerelease) (cpplib) (x86-64 Linux/ELF)
ignoring nonexistent directory "/usr/local/include/g++-v3/x86_64-linux-gnu"
ignoring nonexistent directory "NONE/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/g++-v3
 /usr/local/include/g++-v3/backward
 /usr/local/include
 /usr/local/lib/gcc-lib/x86_64-linux-gnu/3.1/include
 /usr/local/x86_64-linux-gnu/sys-include
 /usr/local/x86_64-linux-gnu/include
End of search list.
---------------------------- clip -------------------------------------

 From where on the earth the "NONE/include" comes, hasn't yet come clear to
me... Ok, it and the 'GPLUSPLUS_INCLUDE_DIR/backward' could be documented in
the gcc-3.1-texinfo's now... As usually just building the binaries, not the
manual, has been done.

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



More information about the crossgcc mailing list