This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [committed] Fix IRIX fallout from Solaris mklibgcc changes


Eric Botcazou <ebotcazou@libertysurf.fr> 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.

Thanks.

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.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]