From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4662 invoked by alias); 22 Sep 2004 20:48:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4555 invoked from network); 22 Sep 2004 20:48:48 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.10) by sourceware.org with SMTP; 22 Sep 2004 20:48:48 -0000 Received: (qmail 16638 invoked from network); 22 Sep 2004 20:48:47 -0000 Received: from localhost (HELO ?192.168.0.105?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 22 Sep 2004 20:48:47 -0000 Message-ID: <4151E52B.1030000@codesourcery.com> Date: Wed, 22 Sep 2004 21:56:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: Geoffrey Keating CC: "E. Weddington" , gcc@gcc.gnu.org Subject: Re: How to stop GCC from searching for components in --prefix on Windows host? References: <4151A867.5030301@evcohs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg01315.txt.bz2 Geoffrey Keating wrote: >"E. Weddington" 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