Bug 37995 - using <stdio.h> fails if gcc invoked in a directory which has a subdirectory called "gcc"
Summary: using <stdio.h> fails if gcc invoked in a directory which has a subdirectory ...
Status: RESOLVED DUPLICATE of bug 38966
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.3.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-02 08:47 UTC by Michael Vanier
Modified: 2012-08-15 21:27 UTC (History)
5 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
build script for gcc on Arch Linux (1.34 KB, text/plain)
2008-11-03 07:37 UTC, Michael Vanier
Details
Simple repro for "gcc" subdir in PATH bug. (1.26 KB, text/plain)
2012-08-15 21:27 UTC, Tom Tignor
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Vanier 2008-11-02 08:47:35 UTC
I tried to compile the following trivial program, called 'hello.c':

#include <stdio.h>

int main(void)
{
    printf("hello, world!\n");
    return 0;
}

using gcc, in a directory which had a subdirectory called "gcc".  This caused the compile to fail with the following output:

> gcc hello.c 
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
In file included from /usr/include/stdio.h:75,
                 from hello.c:1:
/usr/include/libio.h:332: error: expected specifier-qualifier-list before ‘size_t’
/usr/include/libio.h:364: error: expected declaration specifiers or ‘...’ before ‘size_t’
/usr/include/libio.h:373: error: expected declaration specifiers or ‘...’ before ‘size_t’
/usr/include/libio.h:489: error: expected declaration specifiers or ‘...’ before ‘__gnuc_va_list’
/usr/include/libio.h:491: error: expected declaration specifiers or ‘...’ before ‘__gnuc_va_list’
/usr/include/libio.h:493: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘_IO_sgetn’
In file included from hello.c:1:
/usr/include/stdio.h:312: error: expected declaration specifiers or ‘...’ before ‘size_t’
/usr/include/stdio.h:319: error: expected declaration specifiers or ‘...’ before ‘size_t’
/usr/include/stdio.h:347: error: expected declaration specifiers or ‘...’ before ‘__gnuc_va_list’
/usr/include/stdio.h:352: error: expected declaration specifiers or ‘...’ before ‘__gnuc_va_list’
/usr/include/stdio.h:355: error: expected declaration specifiers or ‘...’ before ‘__gnuc_va_list’
/usr/include/stdio.h:361: error: expected declaration specifiers or ‘...’ before ‘size_t’
/usr/include/stdio.h:363: error: format string argument not a string type
/usr/include/stdio.h:365: error: expected declaration specifiers or ‘...’ before ‘size_t’
/usr/include/stdio.h:366: error: expected declaration specifiers or ‘...’ before ‘__gnuc_va_list’
/usr/include/stdio.h:367: error: format string argument not a string type
/usr/include/stdio.h:678: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘fread’
/usr/include/stdio.h:684: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘fwrite’
/usr/include/stdio.h:706: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘fread_unlocked’
/usr/include/stdio.h:708: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘fwrite_unlocked’

The compile works fine if there is no subdirectory called "gcc".  Although this seems trivial, some programs' source code do indeed have subdirectories called "gcc" and this causes them to fail to compile.  I don't know if this is intended behavior or not, but I can't find any information about it in the gcc documentation.  This compile was on an up-to-date Arch Linux system with gcc 4.2.3 which I compiled myself from source.  I have tried it on a Mac Pro using gcc 4.0.1 and the problem does not manifest in that version.  gcc 4.2.3 was built with standard compilation options; the only non-standard configure option was --enable-languages=c,c++,objc and there were no options used for make or make install.

If the -save-temps option is passed to gcc:

> gcc -save-temps hello.c

the result is:

> gcc -save-temps hello.c
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

and when gcc is run on hello.i, the errors output are the same as those above.

Interestingly, when I manually invoke cpp to generate hello.i:

> cpp hello.c > hello.i
> gcc hello.i

there are no errors and the a.out file generated works as intended.  This is with cpp version 4.2.3, created in the same compile as that which created gcc.  However, substituting gcc -E for cpp doesn't work:

> gcc -E hello.c > hello.i

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
Comment 1 Richard Biener 2008-11-02 11:02:55 UTC
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?
Comment 2 Michael Vanier 2008-11-03 07:37:49 UTC
Created attachment 16613 [details]
build script for gcc on Arch Linux

See other posts for this bug.
Comment 3 Michael Vanier 2008-11-03 07:38:30 UTC
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.

Comment 4 Brian Dessent 2008-11-03 23:23:18 UTC
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.
Comment 5 Michael Vanier 2008-11-04 11:07:34 UTC
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.
Comment 6 Michael Vanier 2008-11-04 11:08:32 UTC
Oops, I meant GCC_EXEC_PREFIX is not defined, not GCC_EXEC_PATH.

Comment 7 Andrew Pinski 2008-11-15 00:40:13 UTC
I compile all the time in a directory which contains a gcc directory on GNU/Linux, Darwin and even under windows.
Comment 8 Michael Vanier 2008-11-15 00:50:03 UTC
(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. 
Comment 9 Andrew Pinski 2008-11-15 00:54:07 UTC
(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.
Comment 10 Michael Vanier 2008-11-15 01:01:45 UTC
(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
Comment 11 pinskia@gmail.com 2008-11-15 01:40:52 UTC
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
>
Comment 12 Dov Feldstern 2008-12-21 13:04:12 UTC
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
Comment 13 Andrew Pinski 2009-01-26 19:23:57 UTC

*** This bug has been marked as a duplicate of 38966 ***
Comment 14 Tom Tignor 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.
Comment 15 Tom Tignor 2012-08-15 21:27:31 UTC
Created attachment 28022 [details]
Simple repro for "gcc" subdir in PATH bug.