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

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

David Connelly wrote:
> 
> 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.

 Yes, there are weird things in the cross-GCC build now...
The first thought is that there must be some sanity in them,
but perhaps there aren't any...

 The fact now is that during the build the target headers will
be 'seen' by the fixincludes and fixproto, whatever they then
try to do to the headers, only if they are installed into the
'$(build_tooldir)/sys-include'...

 But as the '-I$(build_tooldir)/include' in the GCC_FOR_TARGET
options shows, they must also be in their normal install place.
Building glibc or newlib installs them there, not into the
'$(build_tooldir)/sys-include'.

 All the problem cases presented here have been the special
"doing this first time, perhaps building from scratch", but
much more common case should be the normal 'upgrade the GCC'-
build, ie. upgrading a working cross-compiler from gcc-2.95.2
to 2.95.3 or something. Should the '--with-headers=' be used
then or the 'sys-include' linked to the 'include' or what?
My opinion is that nothing should be done, GCC should know
where the target headers are, just as it knows where they are
when it is used in a normal compile.

 So the special first-time case should be as much as possible
similar to the normal upgrade-case, the target stuff being in
the '$prefix/$target' (or '$(build_tooldir)') directory in
their normal install directories, 'bin', 'lib' and 'include'.

 The GCC-manual clearly says that fixincludes should see the
headers in '$prefix/$target/include', fix them if needed and
copy the fixed headers into the GCC_INCLUDE_DIR. That the GCC
build now doesn't follow this simple rule, is really a BIG BUG,
IMHO... 

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

 The 'limits.h' is not the only problem, the 'stddef.h', 'stdarg.h'
and 'varargs.h' are provided with quite many targets but the GCC
sources assume that they aren't ever and installs its own ones into
'gcc/include' and later into the GCC_INCLUDE_DIR.

 During the libiberty/libstdc++-build, the GCC_FOR_TARGET is then
not used any more, the CC_FOR_TARGET replaces it, please see the
main 'Makefile.in' in the GCC-sources. This doesn't have the
'-I$(build_tooldir)/include' option, so the GCC's own headers will
be used while compiling libiberty and libstdc++.  And this may cause
problems with the 'va_*' stuff or something. I had this problem when
trying gcc-3.0-20010507 prerelease for the 'i386-mingw32msvc' target.
The Mingw-headers provide their own 'stdarg.h', 'stddef.h' and
'varargs.h'.

 With gcc-2.95.2 the target headers weren't found at all in this stage,
while they were found during the GCC-build (in the 'gcc' subdir),
because of the missing '-I'-option and the search paths going via the
'$prefix/lib/gcc-lib/$target/2.95.2'. The gcc-2.95.3 sources have
fixed this search problem now, but the 'gcc/include' is still searched
first while building libiberty and libstdc++, not the original target
headers, as is done with building 'libgcc.a'. And after the GCC-install
the headers in the GCC_INCLUDE_DIR will be found first...

 Ok, my suggestion is that the GCC-build should check whether the
target headers provide the 'limits.h', 'stddef.h', 'stdarg.h' and
'varargs.h', fix them if needed and then copy the fixed ones into
the 'gcc/include' (and into the GCC_INCLUDE_DIR later), or not do
anything if these headers are ok, not just use its own ones from
the 'gcc/ginclude' in every case.

 Perhaps it is safe to let the fixincludes etc. to see the target
headers now, earlier any already-fixed headers were converted into
a real mess, but still I cannot understand why the duplicates in
the 'sys-include' are necessary (source-bloat), why the 'include'
cannot still be the place as the GCC-manual says and has said since
RMS wrote the manual...

 If the '--with-headers=' would cause the broken headers to be
copied into the 'sys-include', then being fixed during the GCC-build
and the fixed target headers then being copied into the 'include', I
would understand the idea better... Currently the fact is that all
targets may have bugs in their headers and while using the headers
they will be fixed here and there and the bugs (hopefully) reported
to the maintainers.

 The Cygwin, Mingw, DJGPP2, glibc, newlib etc. free headers are under
continuous fixing. Sometimes the fixes are 'local', for instance the
'sys/config.h' in the newlib-headers has been fixed very much by me.
So letting any kind of automatic fixing spoil my fixed headers is the
last thing I would wish...

 Maintaining some untouched broken target headers for the GCC-builds
sounds absurd, just as that people will build a cross-compiler only
once, starting from scratch... "When at last you do succeed, never
do it any more", as the rule in the "Unmarried mother" in the Heinlein
book says... So the GCC-build should succeed when the target headers
are already fixed and installed in the $prefix/$target/include, as
is the case after the glibc and newlib builds (using some older GCC).

 In the 'limits.h' with glibc-case this 'feature' is clearly seen,
FSF seems to be just like MS, although there are bugs like this with
the 'sys-include' and 'include', they are claimed to be just 'features',
not bugs, or being 'current practice'... Ok, I haven't done a bug
report about this, why should anyone do when the clash is so obvious
and there are so many GCC maintainers on this list?  Searching the
'gcc/install.texi' for the GCC_INCLUDE_DIR and reading the text from
its description (why not also for the CROSS_INCLUDE_DIR, the
'sys-include'), reveals where the BIG BUGs lie...

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