Auto unit test suite hangs due to locked mutex

I have searched the net for some indication of what I might be dealing with but have come up empty. This is on a Fedora Core 2 system running GCC 3.3.3. Boost was installed via RPM: # rpm -q boost boost-1.32.0-3.1.2 # I have a reasonably small auto unit test suite via Boost with 48 small discrete tests. It has been running fine previously. There are no tests that are known to invoke mutexes, Boost or otherwise. When we previously built Boost manually, this was not an issue; we're now trying to use the standard RPMs to make distribution/release building simpler. There is possibly an issue in how we're linking to libraries in our automake since those had to be changed to use the RPM installed libraries rather than our previously home-built ones. However, the make (compile, link, etc.) throws no errors, etc., and so we have no indication other than this hang that this is indeed where the problem lies. I had these make files, etc. working fine on a similarily installed system that instead ran FC4 with gcc 4.0.1 and Boost was installed as an RPM but at boost-1.32.0-6. When I copied to the FC2 system and set it up, I now see the issue. The lone symptom is that the test suite seems to complete but then hangs afterwards, apparently deadlocked on a mutex. When I run the test program under --log_level=all, I get the following output: ------------ $ mytestsuite --log_level=all Running 48 test cases... Entering test suite "Auto Unit Test" Entering test case "CounterConstruction" [...specific test output...] Leaving test case "CounterConstruction" [...more test cases...] Entering test case "DataNodeEqualityTest" [...specific test output...] Leaving test case "DataNodeEqualityTest" Leaving test suite "Auto Unit Test" *** No errors detected -------------- ...and then it just hangs without returning to the command line until I ctrl-C. When I run it under gdb to get a stack trace, I get the following session: -------------- $ libtool gdb mytestsuite *** Warning: inferring the mode of operation is deprecated. *** Future versions of Libtool will require -mode=MODE be specified. GNU gdb Red Hat Linux (6.0post-0.20040223.19rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /home/build/<ourpath>/.libs/lt-mytestsuite Error while mapping shared library sections: : Success. Error while reading shared library symbols: : No such file or directory. [Thread debugging using libthread_db enabled] [New Thread -150709728 (LWP 13105)] Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Running 48 test cases... *** No errors detected Program received signal SIGINT, Interrupt. [Switching to Thread -150709728 (LWP 13105)] 0x00272402 in ?? () (gdb) backtrace #0 0x00272402 in ?? () #1 0x0064dcbe in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #2 0x0064ac84 in _L_mutex_lock_29 () from /lib/tls/libpthread.so.0 #3 0x00000000 in ?? () (gdb) quit The program is running. Exit anyway? (y or n) y $ -------------- Finally, a library listing for the test suite executable gives the following: -------------- $ ldd ./.libs/mytestsuite linux-gate.so.1 => (0x001fb000) mylibrary.0 => not found [...related to libtool use?] libxslt.so.1 => /usr/lib/libxslt.so.1 (0x03ec2000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x03a8c000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00644000) libz.so.1 => /usr/lib/libz.so.1 (0x00557000) libxmlwrapp.so.5 => /home/build/<somepath>/dep/lib/libxmlwrapp.so.5 (0x00dcc000) libboost_unit_test_framework.so.1 => /usr/lib/libboost_unit_test_framework.so.1 (0x003bf000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0080c000) libm.so.6 => /lib/tls/libm.so.6 (0x0052c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00763000) libc.so.6 => /lib/tls/libc.so.6 (0x0040f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x003f2000) $ -------------- Any advice to proceed and repair? We'd like very much to be able to use these RPMs than reverting back to our previous homegrown approach. Thank you and kind regards, Richard Newman Crowley Davis Research, Inc.