Re: How to stop GCC from searching for components in --prefix on Windows host?

["E. Weddington" <ericw@evcohs.com>]

Mark Mitchell wrote:

> Geoffrey Keating wrote:
>
>> "E. Weddington" <ericw@evcohs.com> writes:
>>
>>  
>>
>>> Hello!
>>>
>>> I regularly build GCC for the AVR target on a Windows host
>>> (--host=mingw32) usually with some configured --prefix=X. The binary
>>> toolset is redistributed to other users who typically don't install it
>>> in X. There have been some problems where X on the build machine is on
>>> a particular drive, and on the install machine X is on a drive with
>>> removable media, then GCC sometimes craps out and doesn't properly
>>> locate all the components. Is there some way to get GCC to *not*
>>> search for components in the configured prefix, but preserve its other
>>> search rules?
>>>   
>>
>>
>> GCC should already be looking in places based on its location first.
>> This is necessary for correct behaviour if you have one version of GCC
>> installed in $prefix and a different version with the same prefix
>> installed somewhere else.
>>  
>>
> However, it will continue to search in its --prefix location, after 
> its initial search.  (And, there are some things for which it searches 
> for which it is normal not to find the thing in the installed 
> location.)  The really bad situation is when the prefix location 
> exists, and contains the thing, but it is not the version you want.  
> In practice, we try to avoid this by using paths with "CodeSourcery" 
> in them when building packages, but that's not 100% foolproof.
>
> Therefore, I, too, think an option to have GCC not search $(prefix) -- 
> relying purely on its own installed location -- would be a good thing.
>

Ok, based on this, it's now PR #17621 as an enhancement:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621>

BTW, would the IIRC recently taken out --enable-win32-registry=key 
configure flag helped in this situation? Or would it still be searching 
--prefix?

Eric