Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

[Patrick Marlier <patrick.marlier@gmail.com>]

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<rth@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.