[Bug c/37995] using <stdio.h> fails if gcc invoked in a directory which has a subdirectory called "gcc"

[Bug c/37995] using <stdio.h> fails if gcc invoked in a directory which has a subdirectory called "gcc"

[ttignor at us dot ibm.com]

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"

[ttignor at us dot ibm.com]

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"

[pinskia at gcc dot gnu dot org]

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

[dfeldstern at fastimap dot com]

------- 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 /usr/include/stdio.h:75,
                 from hello.c:1:
/usr/include/libio.h:53:21: error: stdarg.h: No such file or directory


-- 

dfeldstern at fastimap dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfeldstern at fastimap dot
                   |                            |com


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"

[pinskia at gmail dot com]

------- 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"
<gcc-bugzilla@gcc.gnu.org 
 > 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

Re: [Bug c/37995] using <stdio.h> fails if gcc invoked in a directory which has a subdirectory called "gcc"

[Andrew Thomas Pinski]

Sent from my iPhone

On Nov 14, 2008, at 5:01 PM, "mvanier at cs dot caltech dot edu" <gcc-bugzilla@gcc.gnu.org 
 > 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"

[mvanier at cs dot caltech dot edu]

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

[Bug c/37995] using <stdio.h> fails if gcc invoked in a directory which has a subdirectory called "gcc"

[pinskia at gcc dot gnu dot org]

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

[mvanier at cs dot caltech dot edu]

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

[pinskia at gcc dot gnu dot org]

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

[mvanier at cs dot caltech dot edu]

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

[mvanier at cs dot caltech dot edu]

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

[brian at dessent dot net]

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

[mvanier at cs dot caltech dot edu]

------- 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=16613&action=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"

[mvanier at cs dot caltech dot edu]

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

[Bug c/37995] using <stdio.h> fails if gcc invoked in a directory which has a subdirectory called "gcc"

[rguenth at gcc dot gnu dot org]

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