Bug 52947 - [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition
Summary: [4.7/4.8 Regression] bootstrap fails due to wrong include search path composi...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.7.0
: P2 normal
Target Milestone: 4.7.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-12 12:05 UTC by Rainer Emrich
Modified: 2013-02-10 23:06 UTC (History)
3 users (show)

See Also:
Host: x86_64-w64-mingw32
Target: x86_64-w64-mingw32
Build: x86_64-w64-mingw32
Known to work: 4.5.3, 4.6.1, 4.6.2, 4.6.3
Known to fail: 4.7.0
Last reconfirmed: 2012-07-05 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Emrich 2012-04-12 12:05:29 UTC 
native x86_64-w64-mingw32 bootstrap using --with-sysroot
This used to work for the 4.6 series.

../../src/gcc-4.7.0/configure --prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0 --with-gnu-as --with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/bin/as --with-gnu-ld --with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/bin/ld --build=x86_64-w64-mingw32 --enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++ --with-gmp-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-gmp-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-mpfr-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-mpfr-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-mpc-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-mpc-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-ppl-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-ppl-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-cloog-include=/SCRATCH/tmp.pzGXGetUXT/install/include --with-cloog-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64 --with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0 --enable-libgomp --enable-fully-dynamic-string --disable-multilib --enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk --with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic'

gcc 4.7.0 bootstrap fails during configuration in libgcc:

checking how to run the C preprocessor... /lib/cpp
configure: error: in `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/x86_64-w64-mingw32/libgcc':
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
gmake[2]: *** [configure-stage1-target-libgcc] Error 1
gmake[2]: Leaving directory `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0'
gmake: *** [all] Error 2 


config.log in libgcc shows:

configure:3893: checking how to run the C preprocessor
configure:3924: /SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/./gcc/xgcc -B/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/./gcc/ -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/lib -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/lib -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/include -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/bin/ -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/lib/ -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/sys-include    -E  conftest.c
In file included from D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/syslimits.h:7:0,
                 from D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/limits.h:34,
                 from conftest.c:10:
D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/limits.h:169:61: error: no include path in which to search for limits.h
configure:3924: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
| 		     Syntax error 


further analysis shows that the include search path composition is wrong.
For gcc-4.6.3 stage1 xgcc the search path is as follows:

nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86_64-w64-mingw32/include« wird ignoriert
nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/mingw/include« wird ignoriert
nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86_64-w64-mingw32/include« wird ignoriert
nicht vorhandenes Verzeichnis »d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86_64-w64-mingw32/sys-include« wird ignoriert
nicht vorhandenes Verzeichnis »d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.6.3\gcc-4.6.3\gcc\../lib/gcc/x86_64-w64-mingw32/4.6.3/include« wird ignoriert
nicht vorhandenes Verzeichnis »d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.6.3\gcc-4.6.3\gcc\../lib/gcc/x86_64-w64-mingw32/4.6.3/include-fixed« wird ignoriert
nicht vorhandenes Verzeichnis »d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.6.3\gcc-4.6.3\gcc\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include« wird ignoriert
nicht vorhandenes Verzeichnis »d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.6.3/gcc-4.6.3/lib/gcc/x86_64-w64-mingw32/4.6.3/include« wird ignoriert
nicht vorhandenes Verzeichnis »D:/x86_64-w64-trunkd:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../include« wird ignoriert
nicht vorhandenes Verzeichnis »d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.6.3/gcc-4.6.3/lib/gcc/x86_64-w64-mingw32/4.6.3/include-fixed« wird ignoriert
nicht vorhandenes Verzeichnis »d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.6.3/gcc-4.6.3/x86_64-w64-mingw32/include« wird ignoriert
#include "..." - Suche beginnt hier:
#include <...> - Suche beginnt hier:
 D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.6.3/gcc-4.6.3/gcc/include
 D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.6.3/gcc-4.6.3/gcc/include-fixed
 D:/x86_64-w64-trunk/mingw/include
Ende der Suchliste.

As you see here the important search path component D:/x86_64-w64-trunk/mingw/include is ok.
For gcc-4.7.0 in contrast I get:

ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include"
ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/include"
ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include"
ignoring nonexistent directory "d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/sys-include"
ignoring nonexistent directory "d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.7.0\gcc-4.7.0\gcc\../lib/gcc/x86_64-w64-mingw32/4.7.0/include"
ignoring nonexistent directory "d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.7.0\gcc-4.7.0\gcc\../lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed"
ignoring nonexistent directory "d:\msys\scratch\tmp.pzgxgetuxt\gcc-4.7.0\gcc-4.7.0\gcc\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.7.0/gcc-4.7.0/lib/gcc/x86_64-w64-mingw32/4.7.0/include"
ignoring nonexistent directory "D:/x86_64-w64-trunkd:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include"
ignoring nonexistent directory "d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.7.0/gcc-4.7.0/lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed"
ignoring nonexistent directory "d:/msys/scratch/tmp.pzgxgetuxt/gcc-4.7.0/gcc-4.7.0/x86_64-w64-mingw32/include"
ignoring nonexistent directory "D:/x86_64-w64-trunkD:/msys/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include
 D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed
 
Here the composition for the include search path gets wrong:

ignoring nonexistent directory "D:/x86_64-w64-trunkD:/msys/mingw/include"

The component /mingw/include is converted to an absolut windows path before it's appended to the sysroot. That's palin wrong.
The library search path is ok.

Any idea how to solve this?
Comment 1 Richard Biener 2012-04-12 12:57:39 UTC 
I remember Kai did surgery in this place.  Did you identify a patch that caused
this regression?  My bet would be

2011-03-25  Kai Tietz  <ktietz@redhat.com>

        * collect2.c (write_c_file_stat): Handle backslash
        as right-hand directory separator.
        (resolve_lib_name): Use IS_DIR_SEPARATOR instead of
        checking just for slash.
        * coverage.c (coverage_init): Use IS_ABSOLUTE_PATH
        instead of checking for trailing slash.
        * gcc.c (record_temp_file): Use filename_cmp instead
        of strcmp.
        (do_spec_1): Likewise.
...
Comment 2 Rainer Emrich 2012-04-12 15:36:11 UTC 
(In reply to comment #1)
> I remember Kai did surgery in this place.  Did you identify a patch that caused
> this regression?  My bet would be
> 
> 2011-03-25  Kai Tietz  <ktietz@redhat.com>
> 
>         * collect2.c (write_c_file_stat): Handle backslash
>         as right-hand directory separator.
>         (resolve_lib_name): Use IS_DIR_SEPARATOR instead of
>         checking just for slash.
>         * coverage.c (coverage_init): Use IS_ABSOLUTE_PATH
>         instead of checking for trailing slash.
>         * gcc.c (record_temp_file): Use filename_cmp instead
>         of strcmp.
>         (do_spec_1): Likewise.
> ...

To be honest, I don't know. I tried native bootstrapping on x86_64-w64-mingw32 at the beginning of last year but gave up due to the issues found. Lately I managed to bootstrap the 4.6 series with some manual intervention even ada included.
There are still issues, one of them is really fundamental, but that's a different story.

Btw. the PATH composition for --with-local-prefix is messed up the same way.
Comment 3 ralphengels@gmail.com 2012-04-21 09:39:19 UTC 
Just chiming in.
Im also running into this problem in stage2
where it fails to find stdarg.h.
As an experiment i tried reverting kai's work but it still fails to find system headers.
A non bootstrap build works but im having problems with programs using libstdc++. All programs compiled that depends on libstdc++ will crash with initialization error 0xc000005. My machine is Win7 64. All previous gcc versions build fine btw. And work also. I have tried with versions compiled by other parts and the problem persists.
Comment 4 ralphengels@gmail.com 2012-05-13 15:15:10 UTC 
Adding 
--disable-build-poststage1-with-cxx \
--disable-build-with-cxx \
allows the full bootstrap on windows with mingw64.

Something is broken with C++ though as anything that links to libstdc++ will crash with the executable has stopped working error (exceptions ?).
 
I hope my findings can shed some light on this.
Comment 5 Richard Biener 2012-06-14 08:16:20 UTC 
GCC 4.7.1 is being released, adjusting target milestone.
Comment 6 Kai Tietz 2012-07-05 11:42:25 UTC 
So, issue tracked down.  It isn't related to the change I did for 4.7 version.  At least not in a direct way.  My changed fixed some issues, which now shown a hidden issue about msys' make, which changes happily arguments containing a POSIX-path to absolute DOS-style paths.
By this NATIVE_SYSTEM_HEADER_DIR (which is /mingw/include) to something like 'D:/msys/mingw/include'.  As native system-header-directory gets additionally prefixed by the specified sysroot, this leads to merging of two absolute DOS-style paths.

So solution for this might be to redefine NATIVE_SYSTEM_HEADER_DIR within target's mingw32.h header for cases that TARGET_SYSTEM_ROOT is defined back to '/mingw/include'.
Comment 7 Kai Tietz 2012-07-06 18:54:24 UTC 
Author: ktietz
Date: Fri Jul  6 18:54:20 2012
New Revision: 189338

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189338
Log:
        PR bootstrap/52947
        * config/i386/mingw32.h (NATIVE_SYSTEM_HEADER_DIR): Define it always
        as "/mingw/include".

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/mingw32.h
Comment 8 Kai Tietz 2012-07-06 18:56:15 UTC 
Author: ktietz
Date: Fri Jul  6 18:56:09 2012
New Revision: 189339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189339
Log:
        Backport from mainline.
        PR bootstrap/52947
        * config/i386/mingw32.h (NATIVE_SYSTEM_HEADER_DIR): Define it always
        as "/mingw/include".

Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/config/i386/mingw32.h
Comment 9 Kai Tietz 2012-07-06 18:58:08 UTC 
Fixed.
Comment 10 Karlson2k 2013-02-10 23:06:21 UTC 
New bug 56279 was introduced with this fix.