[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