[csw-users] 64bit g++ 4.7.2 exception handling ...
Jan Holzhueter
jh at opencsw.org
Thu Mar 21 12:04:21 CET 2013
Am 21.03.13 12:01, schrieb Jan Holzhueter:
> Hi,
>
> Am 21.03.13 11:54, schrieb Dmitri Shubin:
>> Aha, I think I found -- it's direct binding of
>> /opt/csw/lib/amd64/libstdc++.so to libc.so.1 for _Unwind_RaiseException
>> symbol.
>>
>> $ ./a-4.7
>> terminate called after throwing an instance of 'std::runtime_error'
>> terminate called recursively
>> Abort (core dumped)
>> $ LD_NODIRECT=1 ./a-4.7
>> $ echo $?
>> 0
>> $
>>
>> And
>>
>> $ elfdump -y /opt/csw/lib/amd64/libstdc++.so|grep Unwind_RaiseException
>> [1016] DB [2] libc.so.1 _Unwind_RaiseException
>> $ elfdump -y /opt/gcc-4.8/lib/amd64/libstdc++.so|grep Unwind_RaiseException
>> $
>
> It's even more diffrend:
> elfdump -y /opt/csw/lib/libstdc++.so|grep Unwind_RaiseException
> [2610] DBL [4] libgcc_s.so.1 _Unwind_RaiseException
>
> on sparc:
> elfdump -y /opt/csw/lib/libstdc++.so|grep Unwind_RaiseException
> [3348] DBL [3] libgcc_s.so.1 _Unwind_RaiseException
>
> elfdump -y /opt/csw/lib/64/libstdc++.so|grep Unwind_RaiseException
> [1928] DBL [3] libgcc_s.so.1 _Unwind_RaiseException
>
>
> I have no clue why this is diffrend yet and how to fix that.
> But will look into that.
>
sometimes google is nice:
http://paulbeachsblog.blogspot.de/2008/03/exceptions-gcc-and-solaris-10-amd-64bit.html
More information about the users
mailing list