Re: [Boost-users] [wave] Revisited: build errors (partially applies toRC3)

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2007-07-17 11:44:59

Ovanes, 

> I looked through the wave Jamfile.v2 and was able (???) to 
> fix compilation and linking errors of a newer wave release.

Thanks a lot! I'm really sorry to not having been able to look at your
problem yet. 

> First error was that I could not build wave only lib. This 
> was caused by the line nr. 34 (RC3) there is written:
> 
>     /boost/filesystem//boost_filesystem
> 
> The correct filesystem reference at least on my Windows XP 
> VC80 Express Edition machine is:
> 
>     /boost//filesystem

I never saw this syntax before, but I'm not a Boost.Build expert. So I
changed the Jamfile accordingly.

> The next issue relates to the changes you did where linking 
> errors happen. To fix this issue I added a dependency (don't 
> know if this was a correct way to do...) to the thread library:
> 
>     /boost//thread
> 
> At the line 35. This dependency is only needed if wave head 
> is compiled.

Yes you need to reference Boost.Thread as well. 

> I still have a problem that during the initialization phase 
> of wave/spirit's static variables my app crashes. May be you 
> can currently switch off the multi-threaded support in the 
> head revision (or make it available via a macro???), so that 
> I can take files with the conditional processing feature 
> only. 

All you have to do to disable threading support is to define
BOOST_DISABLE_THREADS during compilation of Wave (at least that's the idea).

> Otherwise I am currently blocked because I can either 
> select MT with conditional processing (=>app crashes) or ST 
> without conditional processing. Would be great to get ST with 
> conditional processing.
> 
> The app crashes during the parsing of file: 
> boost\wave\util\cpp_macromap_predef.hpp line 166.
> 
> // __SPIRIT_PP_VERSION__/__WAVE_VERSION__
>     boost::wave::util::time_conversion_helper const
>         compilation_time(__DATE__ " " __TIME__);
> 
> May be there is an assertion, but Visual Studio unfortunately 
> does not show this.

Hmmm, this might be an initialization sequence problem. So I changed the
implementation of the predefined macro support (CVS::HEAD). Now it should
work, could you please try?

Regards Hartmut