[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-12-24 05:04 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #18 from carlos at codesourcery dot com 2006-12-21 04:23 --- This is fixed in 4.3. If I understand correctly the PR should be closed and the Target Milestone marked as 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #17 from carlos at codesourcery dot com 2006-12-07 21:10 --- Eric, All of my patches are now on mainline. The compiler and cpp should no longer search in the configured prefix. Have you tested mainline? There may be a couple of lurking spec file reads that try the configured prefix first. Cheers, Carlos. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #16 from carlos at codesourcery dot com 2006-10-13 19:40 --- 1. Relocated compiler should not search configured prefix. http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html 2. Remove 'NONE' from computed paths http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00096.html 3. Relocated cpp should not search configured prefix. http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00708.html These three patches should prevent the compile from searching the configured prefix for *all* types of files. Eric, your comments are appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #14 from carlos at codesourcery dot com 2006-10-05 08:33 --- GCC_EXEC_PREFIX does not control the search directories for header files. Could you verify that your target actually compiles before applying the patches? Both gcc and cpp need to be taught taught not to search the configured prefix. The patch I provided only the first step. The second step is to improve cpp. I will post a new set of patches for this on the weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #15 from eweddington at cso dot atmel dot com 2006-10-05 12:49 --- (In reply to comment #14) GCC_EXEC_PREFIX does not control the search directories for header files. Could you verify that your target actually compiles before applying the patches? In the test that I did, is I relocated the toolchain on my machine but I also had the original configured prefix available. In this case the toolchain correctly found and built a test program including system header files. When I made the configure prefix directory unavailable (renaming it), then the toolchain failed because it couldn't find the system header files. The toolchain has worked in the past with version 3.4.x, but with a different patch. HTH Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #13 from eweddington at cso dot atmel dot com 2006-10-05 01:56 --- I had to slightly modify patch-2006-08-22-pr17621.diff from Carlos to successfully patch against 4.1.1 (last hunk for gcc.c). It patched successfully, but failed for the avr target in that the toolchain cannot find the system header files for the avr target (from avr-libc). The header files that it cannot find are in install\avr\include (Windows host). I am also configuring with: --enable-win32-registry=WinAVR and adding the correct keys to the registry, and it still fails. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #12 from eweddington at cso dot atmel dot com 2006-09-18 22:42 --- (In reply to comment #11) Created an attachment (id=12115) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12115action=view) [edit] When relocated do not add paths that contain the configured prefix. Patch (patch-2006-08-22-pr17621.diff) does not apply cleanly to 4.1.1. Hunk #7 failed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #10 from eweddington at cso dot atmel dot com 2006-08-22 17:38 --- Subject: RE: Add option to have GCC not search $(prefix) Are you aware of this discussion http://gcc.gnu.org/ml/gcc/2006-07/msg00313.html and this alternative patch, installed in a csl vendor branch http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00684.html Danny Hi Danny, Yes, I was aware of that discussion; I even mentioned it on the GCC list recently. I was not aware of the alternative patch. And I don't think that Carlos was aware of this bug report, even though this bug report stemmed from a discussion on gcc that I had with Mark Mitchell years ago. I've now Cced Carlos on this bug report. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #11 from carlos at codesourcery dot com 2006-08-22 21:02 --- Created an attachment (id=12115) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12115action=view) When relocated do not add paths that contain the configured prefix. Thanks for adding me to the CC. A relocated compiler should never search the configured prefix for programs, libraries or start files. A relocated compiler searching for files in the configured prefix is troublesome. The configured prefix may contain a conflicting toolchain, or a slow network path. The old behaviour of searching the conifgured prefix is not what users expect from a relocated toolchain. Consider 3 types of paths: 1. Relocated paths. 2. Configured prefix paths. 3. Well known system paths. The type 1 and type 3 paths are always added to our search lists. The type 2 paths are only added if the compiler is installed at the configured prefix. This patch groups the 3 path types logically in gcc/gcc.c, and adds the paths based on the wether the compiler is relocated or unrelocated. Could you test this patch out and tell me if it helps? There is a caveat, running 'make -k check' from the object directory may not work. In certain cases, bare-metal targets for example, contains the required start files to build and run the tests. I have an additional patch for this, but it is still in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #8 from wintermute2k4 at ntlworld dot com 2006-08-21 22:35 --- Created an attachment (id=12111) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12111action=view) patch to prevent searching of configured path with relocated toolchain The attached patch against gcc 4.1.1 fixes this issue for me. tested on Debian Sarge and Win2kPro. 2006-08-21 Dave Murphy [EMAIL PROTECTED] *gcc/gcc.c move export of GCC_EXEC_PREFIX to set_std_prefix in prefix.c use relocated path to find standard_exec_prefix/just_machine_suffix/specs *gcc/prefix.c use configured path to check if path needs relocated export set_std_prefix path to GCC_EXEC_PREFIX *gcc/toplev.c set std_prefix with path from GCC_EXEC_PREFIX -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-08-22 00:37 --- (In reply to comment #8) patch to prevent searching of configured path with relocated toolchain Are you aware of this discussion http://gcc.gnu.org/ml/gcc/2006-07/msg00313.html and this alternative patch, installed in a csl vendor branch http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00684.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
