Vladimir Prus wrote:
Neal D. Becker wrote:
Interesting, I sure don't use any mutexes directly. This could be because I use shared_ptr which uses boost::mutex in MT builds. Maybe, you're using MT build of the program_options library?
No, as the above shows, the symbols are in the non-mt version of the library. There is also libboost_python-gcc-mt.a, that's not the one I'm showing above.
Even stranger, here's what I get:
ghost@zigzag:~/Work/boost/stage/lib$ nm libboost_program_options-gcc-d-1_31.a | grep thread ghost@zigzag:~/Work/boost/stage/lib$
Could you do the following 1. Try linking to the debug version of the library. If that fails: 2. Run "nm" with the -l switch, so that we know where the reference to pthread_mutex_init is done.
nm /usr/local/src/boost_1_31_0/stage/lib/libboost_program_options-gcc-1_31.a | grep pthread [nothing] nm /usr/local/src/boost_1_31_0.gcc34/stage/lib/libboost_program_options-gcc-1_31.a | grep pthread U pthread_mutex_destroy U pthread_mutex_init w pthread_mutex_lock w pthread_mutex_unlock w pthread_mutex_lock w pthread_mutex_unlock nm /usr/local/src/boost_1_31_0/stage/lib/libboost_program_options-gcc-d-1_31.a | grep pthread [silence] nm /usr/local/src/boost_1_31_0.gcc34/stage/lib/libboost_program_options-gcc-d-1_31.a | grep pthread U pthread_mutex_destroy U pthread_mutex_init w pthread_mutex_lock w pthread_mutex_unlock w pthread_mutex_lock w pthread_mutex_unlock So, see a pattern here? Only the version built with gcc34 shows this problem. I wonder why? Perhaps in overriding the choice of compiler I caused the problem. BTW, does bjam record anywhere what options were used on the build? I'm not sure I remember what command I used to build with gcc34.