[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