On 13/08/19 09:18 -0600, Tom Tromey wrote:
Jonathan> What I don't understand is why GDB crashes. It should still be able to Jonathan> catch exceptions from a shared library even if linked to libstdc++.a, Jonathan> unless the static libstdc++.a is somehow incompatible with the shared Jonathan> libstdc++.so the shared lib linked to.Jonathan> Is this on GNU/Linux, or something with a different linking model? GNU/Linux, Fedora 29 in particular. I didn't look into why it fails but the gcc docs specifically mention this problem: '-static-libgcc' [...] There are several situations in which an application should use the shared 'libgcc' instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared 'libgcc'. I was able to reproduce it with a simple test program: $ cd /tmp $ cat t.cc void thrower() { throw 23; } $ g++ -fPIC -shared -o libt.so t.cc $ cat a.cc extern void thrower (); int main () { try { thrower (); } catch (...) { } return 0; } $ g++ -o a -static-libgcc -static-libstdc++ a.cc -L$(pwd) -lt $ LD_LIBRARY_PATH=$(pwd) ./a Aborted (core dumped)
This works perfectly for me on F29, but I have no idea why I get different results. I'll look into that separately. Given that the problem does exist, I think being able to disable the GCC build flags for non-GCC components in the build tree makes sense. I'm not sure if Jeff deferring to me means I can approve the patch (normally I can't approve top-level config stuff) but for whatever it's worth, I approve the patch.
