Summary: | libiberty make_relative_prefix_1 mistakes directories for executables | ||
---|---|---|---|
Product: | gcc | Reporter: | Michael Lotz <mmlr> |
Component: | other | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | aschorr, dfeldstern, dickie, gcc-bugs, jakub, mvanier, psmith |
Priority: | P3 | ||
Version: | 4.3.2 | ||
Target Milestone: | --- | ||
Host: | i586-pc-haiku | Target: | i586-pc-haiku |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | ||
Attachments: |
Proposed fix for make_relative_prefix_1
Proposed fix with conditional use of stat based on HAVE_SYS_STAT_H Simple repro for "gcc" subdir in PATH bug. |
Description
Michael Lotz
2009-01-25 14:54:59 UTC
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.
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 *** |