Re: [PATCH RFA] always process -B paths first.

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 4 Sep 2009, Chris Demetriou wrote:

> but the *exact* behaviour isn't specified AFAICT.   I could see an
> argument that says that the each path in the list should be tried with
> and then without the multilib suffix... but I suspect that might have
> negative consequences on some systems.

Doing that would certainly be problematic, for example, if a file is 
supposed to be found in the multilib directory in a sysrooted path and not 
in a prior default-multilib non-sysrooted path.  Depending on the precise 
set of libraries being used in a particular configuration, the correct 
path to find some file may vary from multilib to multilib, meaning that 
searching any non-multilib path before any multilib path could cause the 
wrong version to be found.

In principle, the correct thing is not to search the non-multilib paths at 
all for libraries and startfiles; I'm not sure about specs, but your patch 
does show the libgomp testsuite would need changing to find libgomp.spec 
correctly when only multilib paths are searched.  (In principle, all this 
testsuite logic for finding files in the build tree should also go away, 
replaced by installing in a temporary directory and letting the parts of 
the compiler find each other the way they do once installed.)

Not seaching non-multilib paths was implemented by my patch 
<http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02044.html> (based on 
efficiency concerns), but then reverted as part of Alan Modra's patch for 
PR 20425 <http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00818.html> which 
ensured the multilib paths would at least be searched before all 
non-multilib paths.

Searching multilib paths for libgomp.spec was implemented by Nathan 
Froyd's patch for PR 26165 
<http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00792.html>, and is the 
right thing to do since libgomp.spec is installed in a multilib path and 
is at least potentially multilib-specific.

So by processing some non-multilib -B paths before some other multilib 
paths, your patch would seem to be going in the wrong direction.  Your use 
case is where a multilib, non--B path had a bad file and the non-multilib, 
-B path had a good file.  I do not know all possible uses of -B, but it 
doesn't seem obvious that this case is more likely than the alternative 
your patch would break, where the desired file is present in the non--B, 
multilib directory, the -B multilib directory doesn't have the file and 
the -B non-multilib directory has the wrong file.

There are certainly cases apart from the libgomp testsuite that not 
searching non-multilib directories would break; for one, the use of 
STARTFILE_PREFIX_SPEC in config/mips/st.h, which I discuss in 
<http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00842.html>, is relying on a 
non-multilib path being searched in a multilib-suffixed sysroot, and 
splitting MULTILIB_OSDIRNAMES into sysroot and non-sysroot settings would 
be required to fix that.  It might also break certain lax usages on 
multilibbed systems such as installing libraries in their default "lib" 
directory on x86_64 and expecting a compiler to find them when the proper 
path for such 64-bit libraries is "lib64".

In summary, I think the best fix for your issue is for the libgomp 
testsuite (for non-installed testing) to pass -B options such that 
libgomp.spec is found in the multilib directory relative to the directory 
named in the -B option; I don't know a specific case your patch would 
break, but I think it's moving in the wrong direction.

-- 
Joseph S. Myers
joseph@codesourcery.com