This is the mail archive of the
mailing list for the GCC project.
Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin
- From: Jack Howarth <howarth at bromo dot msbb dot uc dot edu>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 1 Mar 2008 16:16:25 -0500
- Subject: Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin
- References: <20080229141451.GA22429@bromo.msbb.uc.edu> <firstname.lastname@example.org> <20080229173552.GA5296@bromo.msbb.uc.edu> <47C85738.email@example.com> <20080229195213.GA3059@bromo.msbb.uc.edu> <47C863AD.firstname.lastname@example.org> <20080301015844.GA7556@bromo.msbb.uc.edu> <47C8BB75.email@example.com>
While I don't see any particular differences in how
gcc 4.3 branch links its shared libraries with or without
r131198 applied, I do notice that it causes the xgcc created
to be linked against the system libgcc. Without r131198,
only the xgcc in stage1-gcc is linked to the system libgcc.
With r131198, all copies of xgcc created in the build are
linked to the system libgcc instead of that from the build.
Do we have any other targets that link gcc (and xgcc)
with the shared libgcc? I see that i386 and x86_64 linux
creates a gcc (and xgcc) linked to the static libgcc.
If any other targets use a shared libgcc for gcc (and xgcc)
they may be broken as well.
On Fri, Feb 29, 2008 at 06:12:05PM -0800, Mark Mitchell wrote:
> Jack Howarth wrote:
>> One other question. Does the bug fixed by the offending patch...
>> ...merit breaking even a secondary target? Wouldn't it be better
>> to regress that patch out for gcc 4.3.0 (to be reintroduced in
>> gcc 4.3.1 when the problems that it causes for darwin are solved)?
> I think it's important, since, IIUC, it improves our ability to test on all
> platforms. But, I certainly encourage you to figure out why it breaks
> Darwin and work out how to fix it!
> Mark Mitchell
> (650) 331-3385 x713