From: Zachary Mark (zmark_at_[hidden])
Date: 2006-08-07 18:26:50
Vladimir Prus wrote:
> Zachary Mark <zmark <at> cleversafe.com> 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