Bug 48306 - [4.4 Regression] presence of gcc subdir with . in PATH causes breakdown
Summary: [4.4 Regression] presence of gcc subdir with . in PATH causes breakdown
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 4.6.0
: P2 normal
Target Milestone: 4.5.4
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 38966 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-28 00:03 UTC by karl
Modified: 2012-08-16 06:58 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.2.4
Known to fail: 4.3.0
Last reconfirmed: 2011-03-28 09:40:43


Attachments
gcc47-pr48306.patch (924 bytes, patch)
2011-12-19 19:53 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description karl 2011-03-28 00:03:33 UTC
If a directory in PATH contains a subdirectory gcc/ (with executable access), gcc fails to find its subprograms:

$ PATH=/tmp:$PATH
$ mkdir /tmp/gcc
$ gcc hello.c
gcc: error trying to exec 'cc1': execvp: No such file or directory
$ rmdir /tmp/gcc
$ gcc hello.c
$

If this behavior is explained or implicit in the documentation, sorry; I couldn't find it.  It happens in at least gcc 4.5.x and 4.6.0.  I'm sure it wasn't always this way.
Comment 1 Richard Biener 2011-03-28 09:40:43 UTC
Works for me.  How did you configure/install GCC?  What does -v output say
for the compile command?
Comment 2 karl 2011-03-28 21:51:03 UTC
For both gcc 4.5.2 and 4.6.0, I configured it from the original source on ftp.gnu.org, using --prefix=/usr/local/gnu --enable-languages=c,c++, no other arguments.  "make install" to install.

Here is the gcc -v output.  I note that cpp is not even being executed.

$ gcc -v hello.c                                                            
Using built-in specs.                                                           
COLLECT_GCC=gcc                                                                 
Target: i686-pc-linux-gnu                                                       
Configured with: ../gcc-4.6.0/configure --prefix=/usr/local/gnu --enable-langua\
ges=c,c++                                                                       
Thread model: posix                                                             
gcc version 4.6.0 (GCC)                                                         
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=pentiumpro'                   
 cc1 -quiet -v -iprefix /tmp/../lib/gcc/i686-pc-linux-gnu/4.6.0/ hello.c -quiet\
 -dumpbase hello.c -mtune=generic -march=pentiumpro -auxbase hello -version -o \
/dev/shm/cc34H39x.s                                                             
gcc: error trying to exec 'cc1': execvp: No such file or directory

The /tmp/../lib seems like a clear indication it is finding the empty /tmp/gcc directory.

I thought it might be something in my environment causing the failure, but even running with env -i, I get the same error.  It is puzzling that you do not see it.  I can't think of what else would be specific to my installation.

$ mkdir /tmp/gcc
$ env -i PATH=/tmp:/usr/local/gnu/bin gcc hello.c
gcc: error trying to exec 'cc1': execvp: No such file or directory

(the gcc -v output from this env -i run is the same as above.)

Thanks,
karl
Comment 3 Richard Biener 2011-03-29 10:15:45 UTC
Ok, I can reproduce it with

~> env -i PATH=/tmp:/space/rguenther/install/gcc-4.6.0/bin gcc t.c
gcc: error trying to exec 'cc1': execvp: No such file or directory

but not with

~> env -i PATH=/tmp:$PATH gcc-4.6 t.c
t.c: In function 'main':
t.c:10:3: warning: 'used' attribute ignored [-Wattributes]

weird ;)

Note that we try to search for the GCC install dir, it is not statically
compiled in (so that install with DESTDIR works).
Comment 4 Richard Biener 2011-03-29 10:17:46 UTC
Fails since 4.3.0, works with 4.2.4.
Comment 5 Richard Biener 2011-06-27 12:14:40 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 6 Jakub Jelinek 2011-12-19 19:53:43 UTC
Created attachment 26146 [details]
gcc47-pr48306.patch

Not sure if this case is something we need to slow the driver down for, but if yes, this completely untested patch should do that.  I've also fixed a problem where we IMHO can overflow the alloca returned buffer on cygwin or wherever HOST_EXECUTABLE_SUFFIX is used, though have no access to such a system to test that.
Comment 7 karl 2011-12-19 22:59:37 UTC
I hope you will decide that robustness against the execution environment is more important than a few milliseconds of runtime.  I wouldn't have reported it if I hadn't actually run into it in the course of working with the new gcc and been surprised.  It's not like I read the code and observed a theoretical bug :).
Comment 8 Jakub Jelinek 2012-01-02 22:18:25 UTC
Author: jakub
Date: Mon Jan  2 22:18:21 2012
New Revision: 182820

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182820
Log:
	* make-relative-prefix.c (make_relative_prefix_1): Avoid
	stack overflow if PATH contains just a single entry and
	HOST_EXECUTABLE_SUFFIX needs to be used.

	PR driver/48306
	* make-relative-prefix.c: Include sys/stat.h.
	(make_relative_prefix_1): If access succeeds, check also stat
	if nstore is a regular file.

Modified:
    trunk/libiberty/ChangeLog
    trunk/libiberty/make-relative-prefix.c
Comment 9 Jakub Jelinek 2012-01-02 22:20:00 UTC
Fixed on the trunk so far.
Comment 10 Jakub Jelinek 2012-02-09 17:16:27 UTC
Author: jakub
Date: Thu Feb  9 17:16:19 2012
New Revision: 184050

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184050
Log:
	Backported from mainline
	2012-01-26  Jakub Jelinek  <jakub@redhat.com>

	* make-relative-prefix.c (make_relative_prefix_1): Avoid warning
	about using preprocessor directives inside of macro arguments.

	2012-01-02  Jakub Jelinek  <jakub@redhat.com>

	* make-relative-prefix.c (make_relative_prefix_1): Avoid
	stack overflow if PATH contains just a single entry and
	HOST_EXECUTABLE_SUFFIX needs to be used.

	PR driver/48306
	* make-relative-prefix.c: Include sys/stat.h.
	(make_relative_prefix_1): If access succeeds, check also stat
	if nstore is a regular file.

Modified:
    branches/gcc-4_6-branch/libiberty/ChangeLog
    branches/gcc-4_6-branch/libiberty/make-relative-prefix.c
Comment 11 Jakub Jelinek 2012-02-09 21:33:15 UTC
Author: jakub
Date: Thu Feb  9 21:33:11 2012
New Revision: 184069

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184069
Log:
	Backported from mainline
	2012-01-26  Jakub Jelinek  <jakub@redhat.com>

	* make-relative-prefix.c (make_relative_prefix_1): Avoid warning
	about using preprocessor directives inside of macro arguments.

	2012-01-02  Jakub Jelinek  <jakub@redhat.com>

	* make-relative-prefix.c (make_relative_prefix_1): Avoid
	stack overflow if PATH contains just a single entry and
	HOST_EXECUTABLE_SUFFIX needs to be used.

	PR driver/48306
	* make-relative-prefix.c: Include sys/stat.h.
	(make_relative_prefix_1): If access succeeds, check also stat
	if nstore is a regular file.

Modified:
    branches/gcc-4_5-branch/libiberty/ChangeLog
    branches/gcc-4_5-branch/libiberty/make-relative-prefix.c
Comment 12 Jakub Jelinek 2012-03-13 13:28:40 UTC
Fixed in 4.5+, 4.4 is no longer supported.
Comment 13 Jakub Jelinek 2012-08-16 06:58:19 UTC
*** Bug 38966 has been marked as a duplicate of this bug. ***