Re: Problem with GCC 2.95.3 cross and limits.h...

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

David Connelly wrote:

> I seems to me that the default include search path is broken
> in GCC 2.95.3 when building a cross compiler. In gcc/cccp.c,
> include_defaults_array specifies that gcc-lib/<host>/2.95.3/include
> be searched before the compiler tools include directory (i.e.
> those installed by glibc).

 As far as I have seen, this is vice versa, during the build the headers in
'$(build_tooldir)/include', ie. in the '$prefix/$target/include' will be
searched first...  Please check the options in 'GCC_FOR_TARGET' in
the 'gcc/Makefile.in' and you will see...   It is true what you write about
the 'gcc/cccp.c', but the '-I$(build_tooldir)/include' puts this directory
before the built-in ones.

 Again I want to repeat that using the '--with-headers=<something>'
with newlib or glibc headers is basically wrong because it leaves the
'$(build_tooldir)/include' empty and copies the target headers into the
'$(build_tooldir)/sys-include', where the option in GCC_FOR_TARGET
cannot find them at all  and fixincludes tries to fix them before they will be
used....   This is recommended  or even obligatory when the original target
headers are badly broken (VxWorks, old SunOS 4.1.x, Ultrix 4.x,....), but
who cares  to claim that newlib and glibc headers are badly broken, so
they must not be seen by GCC and they must always be fixed for GCC ?

 My opinion is that the '--with-headers=' appearing in so many places
instead of telling about the '$prefix/$target' being the install place for
the target stuff, and the 'include' there for the target headers, is a very
big bug in GCC.....  Its use should be recommended only in those special
VxWorks, SunOS, Ultrix, Xenix etc. cases where the target headers
come from the age of Rolling Stones, CCR, Deep Purple, Uriah Heep
and Led Zeppelin, not forgetting The Doors (the model for the current
"The Windows "? ;-)

 Please check the search-order in 'cpp0' with writing './cpp0 -v' in the
'gcc'-build directory (you probably need to press Ctrl-C in order to
return to the command prompt....) and you will see that both the
'$prefix/$target/sys-include' (CROSS_INCLUDE_DIR) and
'$prefix/$target/include' (TOOL_INCLUDE_DIR) are in the
built-in search-paths, but the '$prefix/lib/gcc-lib/$target/$version/include'
(GCC_INCLUDE_DIR)  comes before them. The CROSS_INCLUDE_DIR
is the equivalent of the SYSTEM_INCLUDE_DIR for a native compiler
(just guess from where the 'sys-' comes from....) and the TOOL_INCLUDE_DIR
is the equivalent of the STANDARD_INCLUDE_DIR for a native compiler
(normally /usr/include).  The place for the standard headers comes always as
the last in the search order....

  When it is very hard to find any person who could tell what on earth to put
into the SYSTEM_INCLUDE_DIR, or even what/where it is in a native GCC,
the situation with the '$prefix/$target/sys-include' is quite the same with a
cross-GCC.  There are hints in the docs about it being suitable for the 3rd-
party headers because the '$prefix/include' (LOCAL_INCLUDE_DIR) is
not enabled for a cross-GCC.... My opinion is that it should be, so the GCCs
in a system could put all the common 3rd-party C-headers there.....  Lets
assume one building tcl/tk-apps for 'ppc-linux', 'arm-linux', 'mips-linux',
'sparc-solaris2.7' etc. and wanting to maintain only a single set of the tcl/tk-
headers.... So where to put them, to be available for all the GCCs ?

  Perhaps I'm wrong, but somehow I think that the X11-headers could also
be target-independent, so a single copy of them for the native and for the
cross-compilers could be enough.....   So I would like to see some discussion
about whether more built-in header search directories would be needed,
or are the current three enough (four for C++), especially whether a common
C-headers directory (LOCAL_INCLUDE_DIR) should be enabled for
cross-compilers too....

  Ok, I went too far, but I have always thought that at least the
'$prefix/$target/include' as the place for the standard headers should be
well-known....  Perhaps it is not....   So it may be that your build method is
broken, you don't have the glibc headers in the '$prefix/$target/include',
but somewhere else.  Please tell us your build method....

> Unfortunately, this means that when including something like "limits.h"

> GCC will always pick up the "fixedincludes" version rather than what is
> installed

> by glibc. Is there an easy way around this other than to
> define my own INCLUDE_DEFAULTS for the arm-linux target?

  This problem may be seen after the GCC install, then the GCC_INCLUDE_DIR
(the 'fixincluded' and the GCC's own headers) will be searched first.  Targets
like
Linux have their own 'stddef.h', 'stdarg.h' and 'varargs.h' and probably those
coming
with GCC don't work as well....

 The 'limits.h' case should work so that first the one in GCC_INCLUDE_DIR is
found, it includes the 'syslimits.h' in the same directory and this uses the
'#include_next <limits.h>' to include the systems own 'limits.h' in
$prefix/$target/include'.
No problems should be seen even the GCC installation....

Cheers, Kai




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