Please help with rebuild on Windows

11 May 2010

Your email is nothing but blackness, if you are going to specify a
foreground color, then make certain to specify a background color,
since some people (like me) have a black background by default, and
your background is set to transparent, and you have black foreground
text, black text on black background makes for it all invisible.  It
is best to send in pure text mode regardless, but if you *have* to
send in richtext/html mode, then *always* set a background color if
you set a foreground color.

On Tue, May 11, 2010 at 4:49 PM, John Dlugosz  wrote:
> I want to use the program-options library, and the copy of boost used by
> this application suite is 1.38.  Using Visual Studio 2008, debug build, the
> resulting program crashes in the variables_map constructor.
>
> My assumption is that the compiler options don’t match:  in particular, a
> stupid thing called
>
>           _HAS_ITERATOR_DEBUGGING=0
>
> is infectious as it causes the STL to generate different code and different
> sized objects.

That is very likely, I set that in everything I compile, have to watch
out for it.

On Tue, May 11, 2010 at 4:49 PM, John Dlugosz  wrote:
> The layout of the boost files doesn’t match the documentation, in that
> bjam.exe is in a subdirectory, and there is no such thing as bootstrap.
> Anyway, I try:
>
> D:\boost_1_38_0> bin\bjam link=static threading=multi variant=debug
> toolset=msvc-9.0 --define=_HAS_ITERATOR_DEBUGGING=0
> Libs\program_options\build

That is because your boost is rather old, 1.38, the bootstrap and such
was added later on (1.40 I think?), you should update, and be sure to
rebuild with the proper define set as you did above.

On Tue, May 11, 2010 at 4:49 PM, John Dlugosz  wrote:
> and it indeed makes a file with the same name as the one my program is
> linking to: libboost_program_options-vc90-mt-gd-1_38.lib, which I copy over
> the original.
>
> It made no difference.

If it made no difference, it might be one of the other options that do
similar breakage like _HAS_ITERATOR_DEBUGGING.  You can test it by
debugging into your project and seeing the generated assembly.

On Tue, May 11, 2010 at 4:49 PM, John Dlugosz  wrote:
> I don’t think that’s the specific problem, though, since it crashes on the
> constructor, not on some later usage from a different translation unit.
>
> The call tree is:
>
>
>
> foo.exe!std::_Tree,std::allocator
>>,boost::program_options::variable_value,std::less,std::allocator
>>
>>,std::allocator,std::allocator
>> const ,boost::program_options::variable_value> >,0> >::_Init()  Line 1180
> + 0xe bytes
>
>
>
> foo.exe!std::_Tree,std::allocator
>>,boost::program_options::variable_value,std::less,std::allocator
>>
>>,std::allocator,std::allocator
>> const ,boost::program_options::variable_value> >,0>
>>::_Tree,std::allocator
>>,boost::program_options::variable_value,std::less,std::allocator
>>
>>,std::allocator,std::allocator
>> const ,boost::program_options::variable_value> >,0> >(const
> std::less,std::allocator
>> > & _Parg=less, const
> std::allocator,std::allocator
>> const ,boost::program_options::variable_value> > & _Al={...})  Line 511
>
>
>
> foo.exe!std::map,std::allocator
>>,boost::program_options::variable_value,std::less,std::allocator
>>
>>,std::allocator,std::allocator
>> const ,boost::program_options::variable_value> >
>>::map,std::allocator
>>,boost::program_options::variable_value,std::less,std::allocator
>>
>>,std::allocator,std::allocator
>> const ,boost::program_options::variable_value> > >()  Line 104
>
>
>
> foo.exe!boost::program_options::variables_map::variables_map()  Line 172 +
> 0x40 bytes
>
>
>
> foo.exe!main(int argc=1, char * * argv=0x01f84190)  Line 179 + 0xb bytes

Hmm, do you have a complete compilable example demonstrating this
problem?  I will not be able to test it (for a week or so), but others
can.

John Dlugosz

OvermindDL1

John Dlugosz

OvermindDL1

John Dlugosz

OvermindDL1

Ilya Sokolov

John Dlugosz

tags

participants (3)