This is the mail archive of the
mailing list for the GCC project.
Re: [committed] Fix IRIX fallout from Solaris mklibgcc changes
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com, zack at codesourcery dot com, joseph at codesourcery dot com, dje at watson dot ibm dot com, amodra at bigpond dot net dot au, David dot Billinghurst at riotinto dot com
- Date: Wed, 19 Jan 2005 09:53:56 +0000
- Subject: Re: [committed] Fix IRIX fallout from Solaris mklibgcc changes
- References: <email@example.com><firstname.lastname@example.org>
Eric Botcazou <email@example.com> writes:
>> As reported a few weeks ago, the Solaris mklibgcc changes broke
>> execution testing for the non-default IRIX multilibs.
> It was not for Solaris, it was for Darwin. The proof is, Solaris is
> still as broken as IRIX was before your patch:
;) Ah yes, sorry about that. I'd thought the original mklibgcc changes
were to do with AMD/Solaris support, but I'd misremembered. It was the
Darwin assert.h thing instead, wasn't it?
> I've opened PR other/19525 to track the breakage.
At the risk of stating the obvious, I think this is wider than just
Solaris and IRIX. Build-directory testing is broken for similarly-
organised *-linux-gnu configurations too. I think it's less likely
to be noticed there because gcc is the system compiler, and so it's
highly likely that the standard library directories will contain a
version of libgcc.so.1. In those circumstances, executables that
use the non-default multilibs will usually load OK, but they'll be
using the system libgcc.so.1, not the newly-built libgcc. This
kind-of invalidates the results.
I see this on mips64-linux-gnu, for example. Test results for the
non-default multilibs are great, but they're using the system DSO
(which is from gcc 3.4, as it happens), not the newly-built one.
I'll add this to this issue notes.