On Mon, Jan 30, 2012 at 12:24:07PM -0500, Patrick Marlier wrote:
> On 01/30/2012 12:15 PM, Jack Howarth wrote:
>> On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote:
>>> Richard Henderson<r...@redhat.com> writes:
>>>
>>>> On 01/25/2012 12:03 AM, Rainer Orth wrote:
>>>>>> Er.. how did we get two copies?
>>>>>
>>>>> The link line boils down to
>>>>>
>>>>> ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc
>>>>> -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o
>>>>>
>>>>> The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder
>>>>> from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1,
>>>>> providing another copy.
>>>>
>>>> So... are we linking with the gcc binary, not the g++ binary?
>>>> Because I thought -shared-libgcc is the default for C++.
>>>>
>>>> If this goes too far down a rat-hole, your original patch is ok.
>>>
>>> The compiler used is currently set in libitm.exp (libitm_init) without
>>> considering the language used. Changing this seems too risky for
>>> stage4. I think we can get away with the following patch instead, which
>>> hardcodes -shared-libgcc for C++. I think it is safe even with
>>> --disable-shared since -shared-libgcc is simply ignored AFAICS, and is
>>> already used unconditionally in libffi.special/special.exp.
>>>
>>> Tested on i386-pc-solaris2.11.
>>
>> FYI, this fix has no impact on the eh-1.C execution failures seen at
>> -m32/-m64 on x86_64 darwin10/11
>> when built with Xcode 4.2(.1).
>
> Problem was discussed here and not same problem as above:
> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html
> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00285.html
>
Patrick,
My mistake. The issue on darwin with Xcode 4.x will either require avoiding
the use of weakref for
darwin or assuming that the user will either use Xcode 3.x or a future fixed
Xcode 4.x release. I am
told the weakref linker bug is fixed upstream but won't make it into Xcode 4.3
(so it is currently
unknown when this fix will be available for Lion).
Jack
> --
> Patrick.
