public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@codesourcery.com>
To: Geoffrey Keating <geoffk@geoffk.org>
Cc: "E. Weddington" <ericw@evcohs.com>,  gcc@gcc.gnu.org
Subject: Re: How to stop GCC from searching for components in --prefix on Windows host?
Date: Wed, 22 Sep 2004 21:56:00 -0000	[thread overview]
Message-ID: <4151E52B.1030000@codesourcery.com> (raw)
In-Reply-To: <m24qlqxhiu.fsf@greed.local>

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.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

  reply	other threads:[~2004-09-22 20:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-22 16:59 E. Weddington
2004-09-22 17:48 ` Dave Korn
2004-09-22 17:56   ` E. Weddington
2004-09-22 18:34     ` Ian Lance Taylor
2004-09-22 18:37       ` E. Weddington
2004-09-22 18:37         ` Ian Lance Taylor
2004-09-22 18:46           ` E. Weddington
2004-09-22 20:46 ` Geoffrey Keating
2004-09-22 21:56   ` Mark Mitchell [this message]
2004-09-22 23:58     ` E. Weddington
2004-09-23  1:29       ` Mark Mitchell
2004-09-23 12:14     ` Dave Korn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4151E52B.1030000@codesourcery.com \
    --to=mark@codesourcery.com \
    --cc=ericw@evcohs.com \
    --cc=gcc@gcc.gnu.org \
    --cc=geoffk@geoffk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).