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

[Mark Mitchell <mark at codesourcery dot com>]

Alan Modra wrote:

>>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?

That would be confidence-inspiring.

>>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).

I agree about startfile_prefixes; I'm not sure about specs, because I
don't know where people tend to really put those.

> 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.

Yes, I think do_spec_path should definitely match find_file.  Maybe the
best approach would be a path-iteration function that made a callback to
a function supplied by the caller so that the iteration logic was in
exactly one place?

> 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.

Great analysis!  If you're willing to follow this up, that would be
really cool.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304