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

[Mark Mitchell <mark at codesourcery dot com>]

Alan Modra wrote:
> This fixes a longstanding gcc/libtool complaint that the library search
> path is wrong when using multilibs.  I've modified gcc -print-search-dirs
> to print the library search path out twice if multilibs are in force,
> first with the appropriate multilib suffixes, then without.  I also do
> the same for LIBRARY_PATH_ENV.  The fact that this just extends the list
> of directories printed should ameliorate concerns that changing
> -print-search-paths like this will break existing uses.
> 
> Bootstrapped etc. powerpc64-linux and powerpc-linux.  OK for mainline?

First, the high order bit.  Printing the list of directories really and
truly searched certainly makes sense in the abstract, but I'm concerned
it might break things given that -print-search-dirs hasn't done that
until now.  I appreciate that only adding to the list is designed to
reduce risk.  However, how do we know that we won't confuse programs
that are currently adding the multilib directory themselves?  In fact,
David Edelsohn told me that there is a libtool branch that does that?  I
believe that I have written scripts that use -print-search-dirs in
combination with -print-multlib-lib to figure out the right place to
look.  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.

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

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?

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

Thanks,

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