Re: [Boost-users] [regex] Static linking woes with gcc 4.0x on FedoraCore

From: David Yon (yon_at_[hidden])
Date: 2006-05-24 08:36:01

John Maddock wrote:

>David Yon wrote:
>  
>
>>One more thought... where would be good places to put some good
>>old-fashioned printfs in the regex code to detect when static
>>initializer/destructors are being called?  Would be interesting to see
>>if I can catch the compiler in the act of destroying my static regexes
>>*after* it has shut down the regex library code.
>>    
>>
>
>Hmm, actually the more I think about it, the less places I can think of that 
>actually do anything at shutdown time.  The best thing would be to get a 
>decent stack trace and/or a test case.
>  
>
Ok, sorry for the firedrill, but I'm now almost certain that Boost is 
the victim here rather than the culprit.  As I said earlier, I'm using 
KDevelop with the AutoMake back-end for doing the actual build.  The 
AutoMake back-end has a linker check-box that lets you statically link.  
Well, you do get an executable which doesn't have any shared lib 
dependencies, but for me, that executable is seriously broken.

I apologize for this being somewhat off-topic, but I'm posting the rest 
of this note anyways in hopes the some poor schmoe in the future gets a 
more informative Google hit than did I this time around...

So after going over to a Fedora Core 3 box with gcc 3.4, I was still 
running into problems.  Only I was back to my original symptom of dying 
in c_regex_traits<char>::init() (which is called during static 
constructor initialization).  It was dying on this line:

   #ifdef BOOST_HAS_THREADS
   re_detail::cs_guard g(*re_detail::p_re_lock);
   #endif

Well actually, it was dying during InitializeCriticalSection(), which 
simply calls pthread_mutex_init().  Except in my case, the top of the 
backtrace was showing 0x00000000.  Initially I attributed this to a 
side-effect of some wildly bad stack or something, but when you look at 
the disassembly, indeed the call to pthread_mutex_init() had been 
resolved to a null address!! (WTF?) 

Running "nm" on the executable shows that pthread_mutex_init is a "Weak 
Symbol", which means that it was legal for it not to resolve and 
therefore it resolved to zero.  I'm not sure what problem the gcc folks 
were trying to solve with that somewhat oddball concept, or why the 
KDevelop "-all-static" checkbox causes this to happen.  I do know that 
for C++, "-all-static" must be doing some serious voodoo, since normally 
it is not at all straightforward to get gcc to cleaning link C++ 
statically.  For a very special flavor of pain, read the following 
thread on that topic:

http://groups.google.com/group/gnu.gcc.help/browse_frm/thread/bfd688b59988567c

At any rate, I've determined that there doesn't seem to be anything 
special about pthreads, because seemingly-inconsequential changes to the 
build will make the problem move around.  I.e., when the problem is that 
I get a segv during exit(), obviously pthread_mutex_init() had been 
properly linked in that time.  So I'm working on getting a static link 
"the hard way" without relying on the broken "-all-static" option.  
Hopefully that is the path to enlightenment.

One good thing to come out of all this is that I discovered that 
including the Boost.regex source in my build is not the black magic I 
thought it would be.  Thanks, John, for that suggestion---it will 
seriously simplify by build scripting.

David Yon
Tactical Software