
I've been having great success with the regex library on Win32 and Linux, up until the time I decided to flip over to using all static linking. What used to be working code suddenly goes belly-up during static constructor initialization, but only when I statically link. When I use dynamic-linking, all appears to be well. I've tried the following permutations, each of which crashes, but each in a slightly different place: - Stock Fedora Core 4 install, with gcc 4.0.0 and boost 1.32 - Upgrade the above to gcc 4.0.2 - Upgrade boost to boost-1.33.1-6.i386.rpm (+boost-devel) - Build boost 1.33 from sources using gcc 4.0.2 When I started, it was dying when running static initializers inside the regex lib. I don't have the exact stack trace right now, but it looked like c_regex_traits<char>::init() was calling a null function pointer somewhere (similar to the top frame shown below). But now that I've come to the last step, it's dying during exit(), with the following backtrace---which isn't terribly helpful, I know: (gdb) backtrace Core was generated by `trquery'. Program terminated with signal 11, Segmentation fault. #0 0x00000000 in ?? () #1 0x08096f63 in __tcf_0 () #2 0x080fa5ee in exit () #3 0x08048d80 in DoQueryAll (ctl=@0xbfaf2a84, ttyname=0x0) at siquery.cpp:472 #4 0x08049826 in main (argc=1, argv=0xbfaf2ec4) at siquery.cpp:320 My DoQueryAll() is calling exit() directly, although I doubt that should make a difference. And again, this All Just Works(tm) when I dynamically link. Dynamic linking is not an option for us---if it came to that, then I'd be seriously looking at refactoring to replace boost.regex with either custom parsing or another regex lib. Besides, bjam *does* build a libboost_regex-XXX.a, presumably it's supposed to work. :-) Now I know that based on the above backtrace, this could be anything. I'm suspecting boost because of the first symptom where the backtrace is in c_regex_traits<char>::init(). So given the dearth of discussion on this category of problem, I'm guessing that perhaps this is a problem with gcc 4.x? Are there any known issues with boost.regex on gcc 4.0.x? Are they fixed in 4.1? Should I just fall back to Fedora Core 3 to get gcc 3.x? Thanks much! David Yon Tactical Software