Brian Dessent <brian@xxxxxxxxxxx> writes: > Shlom Marom wrote: > >> If I compiled the program with shared lib-gcc and with the pthread >> libstdc++ - everything works fine and also the base exception is being >> caught as it should. >> ... >> Shared linking: gcc -o tester_shared main.cpp -pthread -I. >> -shared-libgcc -L/usr/lib -ldl -lpthread -lstdc++ >> Static linking: gcc -o tester_static main.cpp -L/usr/lib/threads >> -pthread -I. -static-libgcc -L/usr/lib -ldl -lpthread `gcc > > A shared libgcc is pretty much required for proper exception handling, I > just don't think you're going to be able to get around that. This > should hold true for pretty much every target so the fact that it works > with static libgcc on Linux is by accident, or perhaps luck. Brian's answer is in general correct. However, there is a case where it works. You can use -static-libgcc when throwing exceptions across shared library boundaries if: 1) gcc is configured to use unwind-dw2-glibc-fde.c instead of unwind-dw2-glibc.c (this happens on GNU/Linux systems and some others--look for uses of t-linux or t-libunwind-elf in gcc/config.gcc). 2) gcc is configured to pass --eh-frame-hdr to the linker (this happens automatically if the linker available when configuring gcc supports this option). 3) The executable and all shared libraries were in fact built by a gcc which passes --eh-frame-hdr to the linker. 4) Your C library has a working copy of dl_iterate_phdr (this is true for recent versions of glibc on GNU/Linux). If all those conditions are true, then unwind information does not need to be registered at program startup. Instead, the unwind library will find it at runtime using dl_iterate_phdr to look for PT_GNU_EH_FRAME segments created by the linker. And in that case -static-libgcc will work. Ian
