[RFC] shared/dylib'ed libgcc for darwin try #2

Andreas Tobler toa@pop.agri.ch
Tue Jun 17 15:09:00 GMT 2003


Hello Alex,

first, thank you for the feedback. You're the first and only one so far.

Alexandre Oliva wrote:
> On Jun 17, 2003, Andreas Tobler <toa@pop.agri.ch> wrote: 
> One thing that jumps out is the unconditional use of
> `-multiply_defined suppress' in the testsuite configuration files.
> This should be reworked so as to use this flag on Darwin alone, or,
> even better, to make it completely unnecessary.

I agree here, and I certainly try to make them darwin only when it comes 
towards an acceptance of dylibs for darwin. For testing purposes it was 
enough.

> FWIW, the changes to the shared library machinery look reasonable, and
> so do the libtool changes, assuming they're just merges from libtool
> CVS mainline.  Otherwise, please make sure any changes you're
> introducing make it to libtool CVS before they make it to GCC, such
> that, when we upgrade to a newer release of libtool, we don't regress.

They are merges from the libtool. Nothing else.

I have some areas where I'm not quite sure if I pass the right 
(linker)flags. So I'd like to get some Apple people's comment on this.

>>While doing the tests I encountered only some minor regressions on
>>c,c++

> By regressions, do you mean failures that were introduced by your
> patch, or maybe that just happened to be there before?  The latter is
> not all that important, but the former should be clearly justified.

Yep, I seem to have them introduced or the machinery does not yet work 
as it should.

E.g,
/Volumes/xufs/gcc-cvs-dylib/gcc/libstdc++-v3/testsuite/20_util/allocator_members
.cc:55: failed assertion `check_new'
FAIL: 20_util/allocator_members.cc execution test.

I also will address these failures when I get some safety that the patch 
more or less looks ok.


Thanks again,
Andreas




More information about the Gcc-patches mailing list