Re: Fix PR20425, multilib paths for -print-search-dirs

[Alan Modra <amodra at bigpond dot net dot au>]

On Thu, Dec 08, 2005 at 07:24:18PM -0800, Mark Mitchell wrote:
> I guess the risk is somewhat minimized in that presumably such
> scripts would just search the multilib directory, and then a
> non-existant subdirectory of the multilib directory, essentially
> appending the multilib name twice.

Yes, that was my thinking too.  I'll note that appending a multilib
suffix in a script is not as easy as it sounds.  The difficulty is that
the multilib_os_dir suffix can be different to the multilib_dir suffix,
so the script needs to somehow figure which suffix to use on a given
path.

> Do we have evidence (like building a pile of packages with both default
> and non-default multilibs on some systems) that this is safe?

Not yet.  Perhaps Andreas will run a SuSE distro build with the patch?

> Second, I've got a few technical questions.
> 
> I believe that we (CodeSourcery) proposed patches for Solaris that made
> the compiler search *only* the correct multilib directories (so, that,
> for example, with -m64 on AMD64, the 32-bit directories were no longer
> searched).  I don't remember if these patches were ever checked in, and
> when I looked at the tree I wasn't sure, but Joseph will know, so I've
> cc'd him.  Assuming that we did in fact check in this Solaris patch,
> then it seems that this patch should avoid mentioning the un-searched
> directories on systems that behave like that, since the goal is to
> really list the actual directories.
> 
> Also, doesn't the fact that we have this inconsistency suggest that
> we've got something wrong in our design?  It seems likewe really ought
> to have one function that is used both to construct the list of
> libraries to print and the list of libraries that are actually searched.
>  Since you had to change build_search_dirs, it seems like there must be
> some other code that's actually doing the searching, adding multilib
> directories; shouldn't that code now be changed not do to that?

Oi!  Just because I'm foolish enough to fix one problem doesn't mean I
want to fix the whole mess!  :-)

Hmm, let's see..

There are two functions involved in searching paths: find_file, which
looks first in all multilib dirs then in all non-multilib dirs, and
find_a_file which is used (except for the invocation in find_file) to
only look in non-multilib dirs.  Searches of exec_prefixes consistently
use find_a_file, searches of startfile_prefixes are rather messy,
sometimes using find_file and sometimes find_a_file.  Library files (%s
in specs and -print-file-name= or -print-libgcc-file-name on the command
line) all use find_file.  %include, %include_noerr and searching for
specs files use find_a_file.  If we are worried about inconsistency,
this should be fixed.  Off the top of my head, I think all
startfile_prefixes searches ought to use find_file (and perhaps the
specs file search should use exec_prefixes).

do_spec_path (used by %D and %I in specs) introduces further
inconsistencies, primarily because it causes paths to be searched in a
different order.  eg. where find_file would search /usr/lib64, /lib64,
/usr/lib, /lib, ie. all multilibs first, do_spec_path would search
/usr/lib64, /usr/lib, /lib64, /lib, interspersing multilib and
non-multilib dirs.  The solaris patch makes do_spec_path even more
inconsistent, but I guess that patch would not be necessary if
do_spec_path kept the same ordering as find_file.

So, there's some analysis to chew over.  The search order problem seems
the most glaring to me.  I'm willing to write the patches if there is
agreement that fixing these inconsistencies is desirable.

> A nit: build_search_list needs a comment for the new DO_MULTI parameter.

Noted.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre