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.
