RE: --with-headers=$GNUTOOLS/$TARGET/include when configuring gc c,why use this?

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

"Manoj Verma, Noida" <manojv@noida.hcltech.com> quoted the GNU 'install'
docs:

> --with-headers
> Specifies that target headers are available when building a cross compiler.

 Usually they are, after the last GCC and C library install/build for that target
or the GCC builder following those 'other' instructions learned during the past
years, or after reading the "Installing GCC / Building and Installing a Cross
Compiler" from the printed GCC manual (the gcc-2.95.3 one may still be the
last one FSF is selling as a printed book...). Anyway the manual tells that
installing the target C library before the GCC build is obligatory. All the proprietary
targets like Solaris2, HP-UX, AIX, UnixWare, Irix etc., and all those with
'custom' C library (sources may be available somewhere), will require their
C libraries being installed before starting to build GCC.  Even with those
'commercial' Linux distributions, RedHat, SuSE etc. being the targets, the
case is about their C libraries suspected to be 'custom', not built from the
plain vanilla glibc sources without any kind of patches...

 After all the most common case should be that someone builds the GCC
as an update to the old GCC, and the GCC install instructions handle only
this most common case.  I really cannot believe there are persons who
really build GCC only once for a target and then never any more... Ok,
those who build it for the first time are just those having the most troubles,
but they should learn then how to build it for the 2nd, 3rd, 4th etc. time,
every time in the same way. One 'bootstraps' only once with a new target...
 
 So my conclusion is "that target headers are available when building a
cross compiler", otherwise there is no sanity in the whole GCC build...

 Exceptions are those stub-GCCs without 'libgcc.a' etc., which produce
objects from sources without any '#include's in them, or the headers
are not from any standard C library... Maybe the Linux kernel can still
be built without any headers from glibc. The old SCO 3.2 came without
any visible C compiler and visible C headers but its kernel could be
built by compiling some driver sources and linking with prebuilt objects.

 Why someone would like to produce a stub-GCC for some very special
needs, not for compiling apps, is weird... Ok, people buy MS Words
etc. and then use 10% or less of their features and things like this may
cause people to search tools with minimal amount of capabilities...

> The dir argument specifies a directory which has the target include files.
> These include files will be copied into the gcc install directory.

 But the current GCC 3.3.2 manual says about this 'install directory' :

------------------------------ clip --------------------------------------
CROSS_INCLUDE_DIR is used only by cross compilers. GCC doesn't
install anything there.
------------------------------ clip --------------------------------------

 I would call copying being 'installing', but who knows...

> This option with the dir argument is required when building a cross compiler,
> if prefix/target/sys-include doesn't pre-exist. If prefix/target/sys-include
> does pre-exist, the dir argument may be omitted.

 What is very expected is that the '$prefix/$target/sys-include' pre-exists and
the GCC-updater has something there already...

 This directory is aimed for the 'system headers', ie. for the 3rd party headers
which don't belong either to the 'standard headers' (POSIX-like), residing in the
'include', neither to the GCC's own headers. Any GCC for an embedded target
can have those headers from the chip-maker(s), describing the I/O-addresses
etc. and in the Linux case there can be all kind of tcl/tk, Qt, curses, termcap
etc. headers not belonging to the 'standard' glibc headers, unless these are
not put into the LOCAL_INCLUDE_DIR.
  
> fixincludes will be run on these files to make them compatible with GCC.

Ok, the gcc-3.3.2 "Internals" manual tells otherwise about the 'include' :

------------------------------ clip --------------------------------------
TOOL_INCLUDE_DIR is used for both native and cross compilers. It is the
place for other packages to install header files that GCC will use. 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.
------------------------------ clip --------------------------------------

 So the new 'install' docs have that info and the new 'internals' docs tell
otherwise in the "Standard Header File Directories"...

 So the decision about whether to try to "make them compatible with GCC"
has been left to the GCC builder in the cross-GCC case.  In the native case
the headers in '/usr/include' will be handled automatically and it is quite hard
to disable the fixing... Ok, the STAMP_FIXINC and STAMP_FIXPROTO or
something in the resulted $build/gcc/Makefile should control this... The
MinGW-build-host case requires this, the 'fixinc' stuff cannot be built for the
MinGW host (yet).

> <<<Source: http://gcc.gnu.org/install/configure.html>>>

 My suggestion would be to get some sanity into this issue. The chapter
in the GCC Internals should be updated to tell about the new target
dependent and 'backward' C++ directories and what they are for, not only
about the old GPLUSPLUS_INCLUDE_DIR ...

 I would also move the "It is the place for other packages to install header
files that GCC will use." into the description of the CROSS_INCLUDE_DIR
and would put a native GCC to use this instead of the 'include'.  Or much
better when the names are as absurd as they are now, to exchange their
meanings, ie. the CROSS_INCLUDE_DIR being the 'include' and the
'TOOL_INCLUDE_DIR' being the 'sys-include', so these descriptions would
be (with elaborations):

------------------------------ clip --------------------------------------
TOOL_INCLUDE_DIR is used for both native and cross compilers. It is the
place for other packages (3rd party) to install the target dependent header
files that GCC will use. GCC doesn't install anything there.

CROSS_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.
------------------------------ clip --------------------------------------

 Why this naming scheme wasn't used in the first place, seems to be an
eternal secret...  I would also enable the LOCAL_INCLUDE_DIR for cross-
GCCs and change its description to be like:

------------------------------ clip --------------------------------------
LOCAL_INCLUDE_DIR is used for both native and cross compilers. GCC
doesn't install anything there. It is normally `/usr/local/include'. This is
where local additions to a packaged system (3rd party) should place
their common (for all GCCs on the system) header files.
------------------------------ clip --------------------------------------

 After getting these changes made, I would consider stopping my eternal
nagging about these issues...

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