Ping: build testing broken for many multilib targets

[Richard Sandiford <rsandifo at redhat dot com>]

I see Mark's gearing up for a 4.0 branch, so I thought I'd better
ping PR19525.

The PR is about build testing being broken for the non-default multilibs
on many native targets.  Bugzilla has the full details about what's
going wrong, but the upshot is that the dynamic loader can't find
libgcc.so.1 for the non-default multilibs.  This has two potential
consequences:

  (1) It can cause execution to fail outright.  This is what happened
      on targets like IRIX and Solaris, which have no system libgcc.so.1.

  (2) It can pick up another version of libgcc.so.1: either one in the
      user's LD_LIBRARY_PATH or one in the system library path.  The tests
      will then appear to pass, but they aren't testing the newly-built
      libgcc.so.1 at all, which kind-of defeats the object.

(2) is what is happening on mips64-linux-gnu (which has a system libgcc.so.1).
I suspect it's also what's happening on powerpc64-linux-gnu.  In a way,
it's more serious than (1), because it lulls you into a false sense of
security.

IMO this PR is a blocker for 4.0.  "make check" is the documented
testing procedure and really ought to work as expected.

FWIW, the changes all started with Zack's reworking of mklibgcc to fix a
Darwin problem.  There was some discussion of the issue on gcc-patches
between Alan, Eric B. and myself, but so far, there hasn't been any
comment from those involved in the original Darwin problem, or from
any maintainers, so I thought I'd better bring it up here.

So... does anyone have any suggestions about how this could be fixed
without reintroducing the Darwin bug?  The IRIX fix mentioned in the PR
(and already committed) seems to work as a stop-gap measure, but I think
it's really papering over the issue.

Richard