User account creation filtered due to spam.

Bug 17621 - Add option to have GCC not search $(prefix)
Summary: Add option to have GCC not search $(prefix)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 3.4.2
: P2 enhancement
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-22 21:31 UTC by Eric Weddington
Modified: 2006-12-24 05:04 UTC (History)
2 users (show)

See Also:
Host: win32
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-31 20:30:30


Attachments
patch to prevent searching of configured path with relocated toolchain (1022 bytes, patch)
2006-08-21 22:35 UTC, Dave Murphy
Details | Diff
When relocated do not add paths that contain the configured prefix. (2.54 KB, patch)
2006-08-22 21:02 UTC, Carlos O'Donell
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Weddington 2004-09-22 21:31:30 UTC
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.
Comment 1 Andrew Pinski 2004-09-22 22:07:31 UTC
Can you try using --with-sysroot= which should solve all of your problems.
Comment 2 Eric Weddington 2004-09-22 22:19:44 UTC
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
Comment 3 Andrew Pinski 2004-09-22 22:46:32 UTC
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.
Comment 4 Andrew Pinski 2004-09-22 22:50:08 UTC
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?
Comment 5 Eric Weddington 2004-09-22 23:18:09 UTC
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.


Comment 6 Andrew Pinski 2004-09-22 23:27:04 UTC
But which component?
Comment 7 Eric Weddington 2004-09-22 23:31:22 UTC
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.
Comment 8 Dave Murphy 2006-08-21 22:35:08 UTC
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
Comment 9 Danny Smith 2006-08-22 00:37:14 UTC
(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
Comment 10 Eric Weddington 2006-08-22 17:38:00 UTC
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

Comment 11 Carlos O'Donell 2006-08-22 21:02:35 UTC
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.
Comment 12 Eric Weddington 2006-09-18 22:42:33 UTC
(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.
Comment 13 Eric Weddington 2006-10-05 01:56:15 UTC
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
Comment 14 Carlos O'Donell 2006-10-05 08:33:42 UTC
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.
Comment 15 Eric Weddington 2006-10-05 12:49:22 UTC
(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
Comment 16 Carlos O'Donell 2006-10-13 19:40:37 UTC
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.
Comment 17 Carlos O'Donell 2006-12-07 21:10:52 UTC
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.
Comment 18 Carlos O'Donell 2006-12-21 04:23:37 UTC
This is fixed in 4.3.

If I understand correctly the PR should be closed and the "Target Milestone" marked as 4.3?
Comment 19 Andrew Pinski 2006-12-24 05:04:27 UTC
Fixed.