Vladimir Prus wrote:
Zachary Mark
writes: Hello,
Our application is using boost::program_options to parse commandline arguments. We have found that when we perform our own builds of boost from source code, program_options freezes the application hard at variable points in the code (a step through in GDB confirms this). However, when we use pre-built binaries of the program_options library for any of our target OSes (Debian stable, Centos 4, Fedora 4) the application runs properly.
We are also using the boost::thread library. Are there thread safety or interaction issues between thread and program_options that I am not aware of? We are using 1.32 due a change in the behavior of program_options in 1.33. This script shows how we are building boost.
You did not indicate where the library hangs (i.e. did not provide a complete backtrace). If it's in some threading-related function, it means that you're using wrong version of the library. If you application is multi-threaded, you must link to MT build of program_options. One important aspect of this is that MT mode changes layout of shared_ptr, which is used in program_options public interface, so mismatch in MT mode between the library and the program causes sure problems.
After some testing, I've determined that it is definitely a library mismatch (this is what I expected it to be, actually). A straight up bjam build without the build script and then manually copying the appropriate library works fine. Using the script-produced library produces the hang (I did a stack trace and it looks like it is getting hung up on a thread wait). I'm not sure what the issue could be with the build script but it's no longer in Boost-land in terms of what is causing the hang. Thanks for the assistance. -- Zach