This is the mail archive of the
mailing list for the GCC project.
Ping: build testing broken for many multilib targets
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Cc: zack at codesourcery dot com, mark at codesourcery dot com
- Date: Sun, 06 Feb 2005 10:18:46 +0000
- Subject: Ping: build testing broken for many multilib targets
I see Mark's gearing up for a 4.0 branch, so I thought I'd better
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
(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
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.