Re: Ping: build testing broken for many multilib targets

[Mark Mitchell <mark at codesourcery dot com>]

Richard Sandiford wrote:
> 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:

I agree that this is very important.

> FWIW, the changes all started with Zack's reworking of mklibgcc to fix a
> Darwin problem.

Yes.  I've actually asked Apple to volunteer some time to fix the 
problems that Zack introduced, since Zack was originally helping them 
out, but so far there hasn't been any sign that Apple's going to help out.

I agree that Zack's responsible, ultimately.  And, I don't think it's 
practical to revert the entire train of patches that got us here, though 
I suppose if someone actually put together that patch, I'd consider it. 
 Then, darwin would again be broken, but I suppose Apple would fix 
that. :-)

I think that the "flat" layout is just wrong.  The right layout is the 
same as the one used in the installed tree (modulo 
MULTILIB_{OS,}DIRNAMES, I guess).  That's the right thing, for lots of 
reasons -- not least because there's no point in being different from 
the installed tree, unless there's a compelling reason.  That means that 
I think that the old layout's "libgcc_s_<multilib>.so" links are bogus.

I've heard people suggest that these links were a win in that it made it 
possible to avoid putting as many directories in LD_LIBRARY_PATH at 
run-out-of-builddir time, but I think that's specious; eliminating the 
differences between build and installed trees is more important.

So, the question is (a) how do we get to the setup that mirrors the 
build tree, and (b) what do we have to do to DejaGNU to make that work 
when running tests?

I think (b) is pretty easy; the hard part is to go through each of the 
t-files and do (a).  And, I'm not really seeing a very good incremental 
approach that doesn't add a lot more work.  But, I don't think that it's 
 going to be *that* hard.

Who's volunteering?

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