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

["David Connelly" <dac at onebox dot com>]

I guess what I way trying to say is that the resulting
compiler does not handle limits.h correctly. You are
correct in that the build works just fine. After looking
at the makefiles more carefully I noticed that gcc-lib's
limits.h is generated differently depending on whether
it finds a limits.h in the sys-include directory (i.e.
copied from --with-headers). If sys-include contains a
limits.h header file, then the one generated in gcc-lib
will recursively include that after defining whatever
definitions are required by gcc. Otherwise, you will only
get the definitions in gcc-lib's limits.h which is a subset
of glibc's limits.h. Since cpp's default include path always
searches gcc-lib's include directory containing the fixed
limits.h first, then the two obvious solutions for this
problem would be to include glibc's headers in --with-headers
(I agree this is bad, and you cannot specify more than one
directory with this option anyway) or change cpp's default
include path to search LOCAL_INCLUDE_DIR *before* fixincludes,
as it does for non-cross compilers. I think it would also
work just to search TOOL_INCLUDE_DIR before fixincludes.

- David

---- Kai Ruottu <karuottu@freenet.hut.fi> wrote:
> 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
> 
> 
> 
> 

__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com


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