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 jos...@codesourcery.com
