I'm having a problem statically linking a big c++ application on Centos4. I can make it work on Centos5 and that's great. I just need to figure out a way to reproduce the problem on a small test case. The specific problem is that when I throw an exception, I get a segfault. It only happens on Centos4, and only on ia-32 machines. In an act of desparation I disassembled the bit of code that's segfaulting and got this: (gdb) disass Dump of assembler code for function _ZN14__gnu_internal10get_globalEv: 0x08579614 <...get_globalEv+0>: call 0x8577c3e <__i686.get_pc_thunk.cx> 0x08579619 <...get_globalEv+5>: add $0x3b31c7,%ecx 0x0857961f <...get_globalEv+11>: push %ebp 0x08579620 <...get_globalEv+12>: mov $0xfffffff8,%eax 0x08579626 <...get_globalEv+18>: mov %esp,%ebp 0x08579628 <...get_globalEv+20>: pop %ebp 0x08579629 <...get_globalEv+21>: add %gs:0x0,%eax <<<--- dies here! <<< 0x08579630 <...get_globalEv+28>: ret 0x08579631 <...get_globalEv+29>: nop End of assembler dump. When it dies, %gs is 0 which looks tls related. Only problem is that when I write tiny test programs to reproduce this, they work fine. %gs is nonzero and everybody is happy. But on my big hulking app, I can throw and catch an exception immediately on entry to main and it segfaults faithfully. Relevant compiler flags are these: g++ -c -o whatever.o -O0 -ggdb -Wno-deprecated -Werror -fPIC -Dmanything -Imanydirs whatever.cpp g++ -o whatever -static -static-libgcc many.o -Lmanydirs -lpthread -lanotherlib -lzlib -lesmtp -lnsl -lrpcsvc -lcrypt -lacl -ldl -lrt -landmanymore So I'm looking for some guidance on what things I could try to isolate this in a smaller app. -- Darrin