Vladimir Prus wrote:

Hi Neal,

...

I have both added current program-options to my boost build tree, and all the usual variants of libboost_program_options-gcc.a, also libboost_python-gcc-mt.a.

Linking against libboost_program_options-gcc.a I get errors about pthread symbols. Adding -pthread fixes it. It looks to me that libboost_program_options-gcc.a is referencing pthread symbols.

nm /usr/local/src/boost_1_31_0.gcc34/stage/lib/libboost_program_options-gcc.a | grep thread U pthread_mutex_destroy U pthread_mutex_init w pthread_mutex_lock w pthread_mutex_unlock w pthread_mutex_lock w pthread_mutex_unlock

Yup,sure is.

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.

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.

Oh, here is how I built with gcc34. Is this the correct procedure? PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc -sGXX=g++34 -sGCC=gcc34 PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc -sGXX=g++34 -sGCC=gcc34 stage