When GCC tries to resolve paths to executables it generates an exec prefix based on argv[0]. It does that using the make_relative_prefix_1 function in libiberty (make-relative-prefix.c). If argv[0] doesn't contain a path (i.e. it only reads "gcc"), make_relative_prefix_1 searches the PATH to find the full path to the current executable. When checking candidates however, it only checks the executable bit to determine whether or not it found the current executable. This means that when there is a directory with the same name as the executable in the PATH, this mechanism will produce a wrong prefix. Attached is a patch that uses stat to determine whether the candidate file is a regular file at all, hence skipping directories.
Created attachment 17181 [details] Proposed fix for make_relative_prefix_1
*** Bug 37995 has been marked as a duplicate of this bug. ***
Subject: Re: New: libiberty make_relative_prefix_1 mistakes directories for executables Your code conditionally includes <sys/stat.h> but doesn't conditionally enable the other code. If sys/stat.h isn't found, perhaps the code could revert to the old access() code?
Created attachment 17189 [details] Proposed fix with conditional use of stat based on HAVE_SYS_STAT_H This only conditionally uses stat() if HAVE_SYS_STAT_H is defined. Not sure about the indentation style at all, sorry.
*** Bug 39278 has been marked as a duplicate of this bug. ***
The currently proposed patch doesn't solve the problem where 'make -k check-libiberty' executed at the top level of the build directory results in gcc being used instead of xgcc. If you execute 'make -k check' in darwin_objdir/libiberty, you get... /sw/src/fink.build/gcc44-4.3.999-20090221/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20090221/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.4/i686-apple-darwin10/bin/ -DHAVE_CONFIG_H -g -O2 -fomit-frame-pointer -I.. -I../../../gcc-4.4-20090221/libiberty/testsuite/../../include -o test-demangle \ ../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c ../libiberty.a whereas if you execute 'make -k check-libiberty' in darwin_objdir, you get the incorrect compiler... gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../gcc-4.4-20090221/libiberty/testsuite/../../include -o test-demangle \ ../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c ../libiberty.a
(In reply to comment #6) > The currently proposed patch doesn't solve the problem where 'make -k > check-libiberty' executed at the top level of the build directory results in > gcc being used instead of xgcc. That's not really the scope of this patch though. This is just to correct the case where a directory is mistaken for an executable. The other issue looks like a separate bug to me.
*** Bug 40548 has been marked as a duplicate of this bug. ***
I ran into the related 37995 bug today (now closed as a duplicate of this one) 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 which I'll attach.
Created attachment 28023 [details] Simple repro for "gcc" subdir in PATH bug.
Dup of PR48306. *** This bug has been marked as a duplicate of bug 48306 ***
Hi Jakub, Can you tell me what gcc version has the fix? Read through 48306 and saw "Fixed in 4.5+" but I have a colleague here who is able to reproduce on 4.5.1. Tom :-) From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: Thomas Tignor/Marlborough/IBM@IBMUS Date: 08/16/2012 02:59 AM Subject: [Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |jakub at gcc dot gnu.org Resolution| |DUPLICATE --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-08-16 06:58:19 UTC --- Dup of PR48306. *** This bug has been marked as a duplicate of bug 48306 ***