[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995 Tom Tignor ttignor at us dot ibm.com changed: What|Removed |Added CC||ttignor at us dot ibm.com --- Comment #14 from Tom Tignor ttignor at us dot ibm.com 2012-08-15 21:12:43 UTC --- I ran into this bug today on gcc version 4.4.6. The bug reproduces simply by having a directory with a gcc subdirectory in your PATH ahead of the directory which holds the gcc binary. I have session output showing the repro procedure. I'll attach that once I find the means or simply cut/paste into another comment. I'll add the same data and similar comments to the surviving duplicate I see here.
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995 --- Comment #15 from Tom Tignor ttignor at us dot ibm.com 2012-08-15 21:27:31 UTC --- Created attachment 28022 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28022 Simple repro for gcc subdir in PATH bug.
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-01-26 19:23 --- *** This bug has been marked as a duplicate of 38966 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #12 from dfeldstern at fastimap dot com 2008-12-21 13:04 --- I'm seeing the same issue, with gcc from debian unstable (gcc (Debian 4.3.2-1) 4.3.2). The problem appears either when a 'gcc' directory (other than the real gcc directory) is found through the PATH, or else GCC_EXEC_PREFIX is set to a path other than the real gcc path. So, here are all kinds of ways I'm able to reproduce, assuming hello.c as above: (1) with a 'gcc' subdir alongside hello.c: PATH=.:$PATH gcc hello.c (note, however, the order is important: PATH=$PATH:. works fine...) (2) with a 'gcc' subdir in .. : PATH=..:$PATH gcc hello.c (3) with a 'gcc' subdir in /tmp: PATH=/tmp:$PATH gcc hello.c (4) regardless of the existence of a 'gcc' subdir: GCC_EXEC_PREFIX=/tmp gcc hello.c (5) the real gcc path is /usr/lib/gcc. However, this still fails: GCC_EXEC_PREFIX=/usr/lib/gcc gcc hello.c (6) OTOH, this works fine (note the trailing slash): GCC_EXEC_PREFIX=/usr/lib/gcc/ gcc hello.c Below are two samples of the output, for (5) and for (1): $ GCC_EXEC_PREFIX=/usr/lib/gcc gcc -v -save-temps hello.c Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -E -quiet -v -iprefix /usr/lib/gcci486-linux-gnu/4.3.2/ hello.c -mtune=generic -fpch-preprocess -o hello.i ignoring nonexistent directory /usr/lib/gcci486-linux-gnu/4.3.2/include ignoring nonexistent directory /usr/lib/gcci486-linux-gnu/4.3.2/include-fixed ignoring nonexistent directory /usr/lib/gcci486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/../../lib/gcc/i486-linux-gnu/4.3.2/include ignoring nonexistent directory /usr/lib/../../lib/gcc/i486-linux-gnu/4.3.2/include-fixed ignoring nonexistent directory /usr/lib/../../lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/local/include /usr/include End of search list. In file included from hello.c:1: /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory In file included from /usr/include/stdio.h:75, from hello.c:1: /usr/include/libio.h:53:21: error: stdarg.h: No such file or directory Alternatively, here's the output without GCC_EXEC_PREFIX, as in (1): $ PATH=.:$PATH gcc -v -save-temps hello.c Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -E -quiet -v -iprefix /tmp/test/../lib/gcc/i486-linux-gnu/4.3.2/ hello.c -mtune=generic -fpch-preprocess -o hello.i ignoring nonexistent directory /tmp/test/../lib/gcc/i486-linux-gnu/4.3.2/include ignoring nonexistent directory /tmp/test/../lib/gcc/i486-linux-gnu/4.3.2/include-fixed ignoring nonexistent directory /tmp/test/../lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /tmp/test/../lib/gcc/../../lib/gcc/i486-linux-gnu/4.3.2/include ignoring nonexistent directory /tmp/test/../lib/gcc/../../lib/gcc/i486-linux-gnu/4.3.2/include-fixed ignoring nonexistent directory /tmp/test/../lib/gcc/../../lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/local/include /usr/include End of search list. In file included from hello.c:1: /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory In file included from
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-11-15 00:40 --- I compile all the time in a directory which contains a gcc directory on GNU/Linux, Darwin and even under windows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #8 from mvanier at cs dot caltech dot edu 2008-11-15 00:50 --- (In reply to comment #7) I compile all the time in a directory which contains a gcc directory on GNU/Linux, Darwin and even under windows. Is . in your PATH environment variable? As I've already mentioned, it works fine if . is not in the path. Now, one can argue that . should not be in the path anyway, but it doesn't seem to me that gcc should be enforcing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-11-15 00:54 --- (In reply to comment #8) Is . in your PATH environment variable? As I've already mentioned, it works fine if . is not in the path. Now, one can argue that . should not be in the path anyway, but it doesn't seem to me that gcc should be enforcing this. Still works on darwin and GNU/Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #10 from mvanier at cs dot caltech dot edu 2008-11-15 01:01 --- (In reply to comment #9) (In reply to comment #8) Is . in your PATH environment variable? As I've already mentioned, it works fine if . is not in the path. Now, one can argue that . should not be in the path anyway, but it doesn't seem to me that gcc should be enforcing this. Still works on darwin and GNU/Linux. It works for me on darwin as well, but with gcc 4.0.1 (which is what MacPorts provides). Which version are you using? I got the problem on gcc 4.3.2 on Arch Linux. Thanks for looking into this. Mike -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
Re: [Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
Sent from my iPhone On Nov 14, 2008, at 5:01 PM, mvanier at cs dot caltech dot edu [EMAIL PROTECTED] wrote: --- Comment #10 from mvanier at cs dot caltech dot edu 2008-11-15 01:01 --- (In reply to comment #9) (In reply to comment #8) Is . in your PATH environment variable? As I've already mentioned, it works fine if . is not in the path. Now, one can argue that . should not be in the path anyway, but it doesn't seem to me that gcc should be enforcing this. Still works on darwin and GNU/Linux. It works for me on darwin as well, but with gcc 4.0.1 (which is what MacPorts provides). Which version are you using? I got the problem on gcc 4.3.2 on Arch Linux. I am using 4.3.0, 4.4.0, 4.1.1 and 4.0.2. On all of the above targets/ hosts. Thanks for looking into this. Mike -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #11 from pinskia at gmail dot com 2008-11-15 01:40 --- Subject: Re: using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc Sent from my iPhone On Nov 14, 2008, at 5:01 PM, mvanier at cs dot caltech dot edu [EMAIL PROTECTED] wrote: --- Comment #10 from mvanier at cs dot caltech dot edu 2008-11-15 01:01 --- (In reply to comment #9) (In reply to comment #8) Is . in your PATH environment variable? As I've already mentioned, it works fine if . is not in the path. Now, one can argue that . should not be in the path anyway, but it doesn't seem to me that gcc should be enforcing this. Still works on darwin and GNU/Linux. It works for me on darwin as well, but with gcc 4.0.1 (which is what MacPorts provides). Which version are you using? I got the problem on gcc 4.3.2 on Arch Linux. I am using 4.3.0, 4.4.0, 4.1.1 and 4.0.2. On all of the above targets/ hosts. Thanks for looking into this. Mike -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #5 from mvanier at cs dot caltech dot edu 2008-11-04 11:07 --- OK, I built a vanilla gcc system from scratch and it's still exhibiting the same problem. However, here's something new: the problem only manifests itself if . (the current directory) is in the path. If it isn't, no problem. $GCC_EXEC_PATH is not defined. Also, (when . is in the path) if I explicitly give the path to gcc: % /pkg/gcc/bin/gcc hello.c it works. But if I don't: % which gcc /pkg/gcc/bin/gcc % gcc hello.c you get the same error message I reported before. This is really weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #6 from mvanier at cs dot caltech dot edu 2008-11-04 11:08 --- Oops, I meant GCC_EXEC_PREFIX is not defined, not GCC_EXEC_PATH. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #4 from brian at dessent dot net 2008-11-03 23:23 ---
Subject: Re: using stdio.h fails if gcc invoked in a directory
which has a subdirectory called gcc
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -quiet -v -iprefix
/home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/ hello.c -mtune=generic
-fpch-preprocess -o hello.i
That -iprefix is the problem. It should not be there. Do you have
GCC_EXEC_PREFIX set in your environment or something? You should not
need this set in normal use of the compiler; try with a clean env.
Also, you are not building a stock gcc because there are these patches
added by your build script:
if [ ${CARCH} = x86_64 ]; then
patch -Np1 -i ../gcc_pure64.patch || return 1
fi
patch -Np0 -i ${srcdir}/gcc-hash-style-both.patch || return 1
patch -Np0 -i ${srcdir}/gcc-java-driver.patch || return 1
It makes it really hard to triage bugs when you report problems against
software build with random unmentioned outside changes. Please try a
vanilla build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-02 11:02 --- Works for me. What is the output if you add -v to the commandline? This may be a packaging bug of your operating system vendor - which is? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #2 from mvanier at cs dot caltech dot edu 2008-11-03 07:37 --- Created an attachment (id=16613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16613action=view) build script for gcc on Arch Linux See other posts for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #3 from mvanier at cs dot caltech dot edu 2008-11-03 07:38 --- The operating system is Arch Linux, and the package manager is Arch-specific and is called pacman. There is a separate package manager for building packages from scratch called ABS (Arch Build System). I'm attaching their build script (called PKGBUILD). However, in this particular case I built gcc myself and installed it in /pkg/gcc. Here is the test you asked for: gcc --save-temps -v hello.c Using built-in specs. Target: i686-pc-linux-gnu Configured with: /src/gcc/gcc-4.3.2/configure --prefix=/pkg/gcc --enable-languages=c,c++,objc Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-save-temps' '-v' '-mtune=generic' /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -quiet -v -iprefix /home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/ hello.c -mtune=generic -fpch-preprocess -o hello.i ignoring nonexistent directory /home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/include ignoring nonexistent directory /home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed ignoring nonexistent directory /home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /home/mvanier/tmp/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.2/include ignoring nonexistent directory /home/mvanier/tmp/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed ignoring nonexistent directory /home/mvanier/tmp/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/include End of search list. In file included from hello.c:1: /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory In file included from /usr/include/stdio.h:75, from hello.c:1: /usr/include/libio.h:53:21: error: stdarg.h: No such file or directory One thing that jumps out at me is that it is using /usr/include and /usr/local/include as the only locations for looking up include files. stddefs.h and stdarg.h are not there, but they aren't there in any other distro I've looked at either, so I assumed that they were somehow handled specially by gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
