Add option to have GCC not search $(prefix), but preserve all other search rules when finding components. The problem that this option would solve is outlined here: <http://gcc.gnu.org/ml/gcc/2004-09/msg01310.html> This affects toolsets that are hosted on Windows.
Can you try using --with-sysroot= which should solve all of your problems.
Subject: Re: Add option to have GCC not search $(prefix) pinskia at gcc dot gnu dot org wrote: >------- Additional Comments From pinskia at gcc dot gnu dot org 2004-09-22 22:07 ------- >Can you try using --with-sysroot= which should solve all of your problems. > > > The documentation for --with-sysroot= is not exactly clear to me wrt this particular instance: |--with-sysroot| |--with-sysroot=|dir Tells GCC to consider dir as the root of a tree that contains a (subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched in there. The specified directory is not copied into the install tree, unlike the options --with-headers and --with-libs that this option obsoletes. The default value, in case --with-sysroot is not given an argument, is ${gcc_tooldir}/sys-root. If the specified directory is a subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved. The first sentence talks about the "root filesystem of the target operating system". I don't see how this applies to the AVR target as it is an OS-less microcontroller, and has no "filesystem" of it's own. Perhaps you can elucidate 1. how enabling this would help on the AVR target, and 2. what exactly should be specified as dir. Thanks Eric
Oh, I did not read your email fully but this should just work if it does not then there is a bug in the windows code.
yes but searching the prefix is always preferred to do, I still don't understand why you don't want it to search prefix as if you don't then there is an error about something being missing is that what you want instead of some wired error?
Subject: Re: Add option to have GCC not search $(prefix) pinskia at gcc dot gnu dot org wrote: >------- Additional Comments From pinskia at gcc dot gnu dot org 2004-09-22 22:50 ------- >yes but searching the prefix is always preferred to do, I still don't understand why you don't want it to >search prefix as if you don't then there is an error about something being missing is that what you want >instead of some wired error? > > > Did you read the email thread that the original description referenced?: <http://gcc.gnu.org/ml/gcc/2004-09/msg01310.html> That explains why. Searching the prefix is not always desired when building and installing to --prefix=X but redistributing the binary toolset where it won't be installed at X, which is typically the case on Windows toolsets.
But which component?
Subject: Re: Add option to have GCC not search $(prefix) pinskia at gcc dot gnu dot org wrote: >------- Additional Comments From pinskia at gcc dot gnu dot org 2004-09-22 23:27 ------- >But which component? > > > IIRC, the executables, the compilers themselves.
Created attachment 12111 [details] 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 <wintermute2k4@ntlworld.com> *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
(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
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
Created attachment 12115 [details] 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.
(In reply to comment #11) > Created an attachment (id=12115) [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.
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
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.
(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
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.
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.
This is fixed in 4.3. If I understand correctly the PR should be closed and the "Target Milestone" marked as 4.3?
Fixed.