Re: Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 5 Dec 2016, Sebastian Huber wrote:

> If we assume that the command line order determines the search order, then its
> not clear why for_each_path() first iterates for all paths with the multilib
> postfix and then without. Shouldn't it iterate over all paths and check
> with/without multilib postfix in each step?

No.  The directory without the multilib postfix is generally the directory 
for another multilib, i.e. always wrong to search, and in case the library 
appears earlier in the non-multilib directories than the multilib ones, 
mixing the search paths (and there may already be some unwanted mixing 
when sysroots are involved) would result in the wrong library being 
chosen.

Unfortunately, getting rid of the search of non-multilib directories 
completely is hard.  It was removed in r96915 
<https://gcc.gnu.org/ml/gcc-patches/2004-11/msg01895.html>.  Then this was 
reverted in <https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00818.html>.  
Furthermore, it turns out there is a case where the existing multilib 
configuration machinery cannot express things correctly without searching 
non-multilib directories.  Specifically, consider the combination of 
MULTILIB_OSDIRNAMES with sysroot suffixes.  This is used by 
config/mips/{t-mti-linux,mti-linux.h}, for example.

MULTILIB_OSDIRNAMES provides directory names used in two ways: relative to 
$target/lib/ in the GCC installation, and relative to lib/ and usr/lib/ in 
a sysroot.  For the latter, we want names such as plain ../lib64, but 
these cannot be used outside the sysroot because different multilibs would 
be mapped to the same directory.  The solution to this issue relies on 
searches without multilib suffixes: you define STARTFILE_PREFIX_SPEC 
(which used to be used more widely before MULTILIB_OSDIRNAMES was added in 
the first place) so sysroot libraries can be found by the combination of 
(sysroot, sysroot suffix, startfile prefix, *no* multilib suffix).

So while this case of MULTILIB_OSDIRNAMES with multiple sysroots makes it 
hard to eliminate the search of non-multilib directories, they should be 
searched as late as possible to reduce the risk of problems from the wrong 
libraries being found.

-- 
Joseph S. Myers
joseph@codesourcery.com