#1408 gcc-4.5.0 problem: compiler cannot find mingwrt headers

closed-fixed
Cesar Strauss
gcc (462)
2014-08-24
2010-03-16
Tatsuro MATSUOKA
No

Hello
This is at first posted to [Mingw-users] list.
http://old.nabble.com/gcc-4.5.0-%3A-Is-flag--I-mingw-include-always-needed---td27901832.html

Thanks to Earnie and Keith Marshall for your immediate response.
Sorry for my bad writing my reports.

My phenomena that I met may come from my MinGW is not installed to C:\MinGW but to C:\Programs\MinGW
C:\Programs\MinGW has been used for in my favor.
(I do not want to make directories in root of the drive if change of the directory position is allow to be moved.)

I tried to compile test.c attached on Msys sh shell
When MinGW is installed in C:\Programs\MinGW.
The result is

$ gcc -o test.o test.c
test.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.

$ gcc -o test.o test.c -I/mingw/include

Msys fstab for mingw
c:/Programs/mingw /mingw

I moved my MinGW directory from C:\Program\MinGW to C;\MinGW

Msys fstab for mingw
c:/mingw /mingw

This time

Tatsu@Shiro ~/program/C/gcctest
$ gcc -o test.o test.c

worked fine without -I/mingw/include

For gcc-3.4.x, gcc-4.4.0, the location of MinGW in not C:\MinGW have been caused no errors from Msys sh shell
when Msys fstab for mingw is set like c:/Programs/mingw /mingw

Anyway I use at the moment, C:/MinGW instead of C:\Program\MinGW

Regards

Tatsuro

Discussion

1 2 > >> (Page 1 of 2)
  •  
    Attachments
    • summary: Complication problem gcc-4.5.0 when MinGW is not installed d --> Complication problem gcc-4.5.0 when MinGW is not installed t
     
  • Keith Marshall
    Keith Marshall
    2010-03-16

    • assigned_to: nobody --> cstrauss
    • summary: Complication problem gcc-4.5.0 when MinGW is not installed t --> gcc-4.5.0 problem: compiler cannot find mingwrt headers
     
  • Keith Marshall
    Keith Marshall
    2010-03-16

    I can confirm this as a regression affecting gcc-4.5.0_20100311-1-mingw32; it may not be apparent to those who install with sysroot == c:/mingw, but it is readily observed when an alternative, but equally valid sysroot is chosen, and no prior installation in c:/mingw exists.

    To reproduce, with parallel installations in d:/usr/MinGW-3.4.5 (GCC-3.4.5) and in d:/usr/MinGW-4.5.0 (GCC-4.5), (and none in C:/MinGW), I have run (under MSYS-1.0.11):

    $ umount /mingw
    $ mount d:/usr/mingw-4.5.0 /mingw
    $ echo '#include <stdio.h>' | gcc -E -o nul -xc -
    <stdin>:1:19: fatal error: stdio.h: No such file or directory
    compilation terminated.

    (The header file is definitely present in the required path):

    $ ls -l /mingw/include/stdio.h
    -rw-r--r-- 1 keith ... 22047 Mar 7 03:31 /mingw/include/stdio.h

    For comparison, the same with GCC-3.4.5:

    $ umount /mingw
    $mount d:/usr/mingw-3.4.5 /mingw
    $ echo '#include <stdio.h>' | gcc -E -o nul -xc -

    completes silently, (i.e. without error).

    Repeating the above, with the '-v' option added, reveals the regression; first for the GCC-3.4.5 case:

    $ echo '#include <stdio.h>' | gcc -v -E -o nul -xc -
    Reading specs from d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/specs
    Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as
    --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
    --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
    --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
    --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
    --enable-hash-synchronization --enable-libstdcxx-debug
    Thread model: win32
    gcc version 3.4.5 (mingw special)
    d:/usr/mingw-3.4.5/bin/../libexec/gcc/mingw32/3.4.5/cc1.exe -E -quiet -v
    -iprefix d:\usr\mingw-3.4.5\bin\../lib/gcc/mingw32/3.4.5/ -Id:/usr/local/include
    - -o nul.exe
    ignoring nonexistent directory
    "d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/include"
    ignoring nonexistent directory "/mingw/include"
    ignoring nonexistent directory "/mingw/include"
    ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.5/include"
    ignoring nonexistent directory "/mingw/mingw32/include"
    ignoring nonexistent directory "/mingw/include"
    #include "..." search starts here:
    #include <...> search starts here:
    d:/usr/local/include
    d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include
    d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/include
    End of search list.

    Ignoring the addition of d:/usr/local/include to the include search path, (I add it using a local specs file customisation), that all seems as it should be; mingwrt header files are found on the second path, d:/usr/mingw-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../include, (which simplifies to d:/usr/mingw-3.4.5/include, the standard installation path for these headers, with a sysroot == d:/usr/mingw-3.4.5).

    Repeating for the GCC-4.5.0 case:

    $ umount /mingw
    $ mount d:/usr/mingw-4.5.0 /mingw
    $ echo '#include <stdio.h>' | gcc -v -E -o nul -xc -
    Using built-in specs.
    COLLECT_GCC=d:\usr\mingw-4.5.0\bin\gcc.exe
    COLLECT_LTO_WRAPPER=d:/usr/mingw-4.5.0/bin/../libexec/gcc/mingw32/4.5.0
    /lto-wrapper.exe
    Target: mingw32
    Configured with: ../gcc-4.5.0_20100311/configure
    --enable-languages=c,c++,ada,fortran,objc,obj-c++
    --disable-sjlj-exceptions --with-dwarf2 --enable-shared
    --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug
    --enable-version-specific-runtime-libs --disable-werror --build=mingw32
    --prefix=/mingw
    Thread model: win32
    gcc version 4.5.0 20100311 (experimental) (GCC)
    COLLECT_GCC_OPTIONS='-v' '-E' '-o' 'nul' '-mtune=i386' '-march=i386'
    d:/usr/mingw-4.5.0/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -E -quiet -v
    -iprefix d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/
    - -o nul -mtune=i386 -march=i386
    ignoring nonexistent directory "c:/mingw/include"
    ignoring nonexistent directory "/mingw/include"
    ignoring duplicate directory
    "d:/usr/mingw-4.5.0/lib/gcc/../../lib/gcc/mingw32/4.5.0/include"
    ignoring duplicate directory
    "d:/usr/mingw-4.5.0/lib/gcc/../../lib/gcc/mingw32/4.5.0/include-fixed"
    ignoring nonexistent directory "d:/usr/mingw-4.5.0/lib/gcc/../../mingw32/include"
    ignoring nonexistent directory "/mingw/include"
    #include "..." search starts here:
    #include <...> search starts here:
    d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include
    d:\usr\mingw-4.5.0\bin\../lib/gcc/mingw32/4.5.0/include-fixed
    End of search list.
    <stdin>:1:19: fatal error: stdio.h: No such file or directory
    compilation terminated.
    gcc.exe: nul: Permission denied

    Note the hard coded addition of the non-existent c:/mingw/include directory to the include search path; the presence of this is, in itself and IMO, an error, which explains why those with sysroot == c:/mingw may not notice the regression. On its own, this error is innocuous; the regression is that the required

    <sysroot>/bin/../lib/gcc/mingw32/3.4.5/../../../../include

    has been omitted, (perhaps having been unintentionally replaced by the hard coded c:/mingw/include, but I offer no evidence to support this hypothesis).

     
  • Cesar Strauss
    Cesar Strauss
    2010-03-17

    Thanks for the report.

    I have identified the issue, as well as a potential fix.

    During the gcc build under MSYS, the Makefile passed the include pathname as:
    -DLOCAL_INCLUDE_DIR=\"/mingw/lib/gcc/mingw32/4.5.0/../../../..include\"

    For some reason, it ends-ups being translated by MSYS as:
    -DLOCAL_INCLUDE_DIR=\"c:/mingw/include\"

    This interferes with the relocation support.

    I hope to avoid triggering the MSYS path translation by configuring with --prefix=c:/mingw instead of /mingw.

    Cesar

     
  • Keith Marshall
    Keith Marshall
    2010-03-17

    > I have identified the issue, as well as a potential fix.

    Thanks Cesar. This is good news.

    > I hope to avoid triggering the MSYS path translation by
    > configuring with --prefix=c:/mingw instead of /mingw.

    I wonder if this is (partly) the reason why Aaron, and Danny before him, used Cygwin to build their releases. It's good to see that you are building with MSYS -- we should be able to support building on our own platform.

    > For some reason, it ends-ups being translated by MSYS as:
    > -DLOCAL_INCLUDE_DIR=\"c:/mingw/include\"

    The "some reason" would be that MSYS recognises its own emulated Unix path name pattern in the variable assignment, and it *always* converts and canonicalises such patterns, translating to a native Win32 equivalent, when passing such strings either as arguments or in the environment, to a native Win32 application; (the compiler tool chain you are using to bootstrap your build comprises native Win32 applications, as does the tool chain you are building).

    As a side issue, (for a different ticket, I think), I have been asking for some time, for a mechanism to *selectively* disable MSYS path translation for individual strings -- not a blanket on or off option, as has been tentatively suggested by others, but which I don't believe will be particularly effective. 99.99% of the time, path translation does exactly the right thing, but unfortunately those 0.01% of corner cases where it goes badly wrong represent just too significant a minority, (and unfortunately for the blanket on/off option, they often occur in admixture with examples of the 99.99% majority cases, even within the same command line.

     
  • Earnie Boyd
    Earnie Boyd
    2010-03-17

    Cesar, I suggest you use --prefix=//mingw instead. I don't know if either will resolve the problem. The issue may happen at the build once the xgcc compiler stub is in action. You may have to resort to some other trickery but as Keith has said, it would be good to be using our own tools to build our distributions.

     
  • Keith Marshall
    Keith Marshall
    2010-03-17

    > [MSYS] *always* converts and canonicalises such patterns,
    > translating to a native Win32 equivalent

    Correction: *canonicalisation* doesn't *always* occur by default, but it does for the particular case in point...

    $ dumpargs \ -DLOCAL_INCLUDE_DIR=\"/mingw/lib/gcc/mingw32/4.5.0/../../../../include\"
    argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe
    argv[1]: -DLOCAL_INCLUDE_DIR="d:/usr/mingw-4.5.0/include"

    ...but...

    $ dumpargs \ -DLOCAL_INCLUDE_DIR=\"/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../include\"
    argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe
    argv[1]: -DLOCAL_INCLUDE_DIR="d:/usr/mingw-4.5.0/bin/../lib/gcc/mingw32/4.5.0/../../../../include"

    ...an inconsistency which suggests a bug in MSYS' path translation logic. Also, notice the apparent effect of pursuing Earnie's suggestion...

    $ dumpargs \ -DLOCAL_INCLUDE_DIR=\"//mingw/lib/gcc/mingw32/4.5.0/../../../../include\"
    argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe
    argv[1]: -DLOCAL_INCLUDE_DIR="//mingw/lib/gcc/mingw32/4.5.0/../../../../include"

    ...which leaves the doubled initial slash in place, but...

    $ dumpargs -DLOCAL_INCLUDE_DIR=\"//mingw\"
    argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe
    argv[1]: -DLOCAL_INCLUDE_DIR="/mingw"

    ...which reduces it; (in this case, it appears that the reduction does not occur when the path extends to a depth of more than one directory)...

    $ dumpargs -DLOCAL_INCLUDE_DIR=\"//mingw/include\"
    argv[0]: d:\usr\sandbox\local\bin\dumpargs.exe
    argv[1]: -DLOCAL_INCLUDE_DIR="//mingw/include"

     
  • Cesar Strauss
    Cesar Strauss
    2010-03-18

    I fixed the canonicalisation issue in the MSYS DLL and released it as 1.0.14.

    Rebuilding gcc with this DLL solved the original issue of the missing include path. I'll update the gcc packages with this fix shortly.

    Regards,
    Cesar

     
  • Cesar Strauss
    Cesar Strauss
    2010-03-19

    I just uploaded gcc-4.5.0_20100311-2,which contains a fix for this issue.

    Regards,
    Cesar

     
1 2 > >> (Page 1 of 2)