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 _______________________________________________ users mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/users
