Re: deadlock in filesystem?

From: Russell Hind (yg-boost-users_at_[hidden])
Date: 2003-07-03 04:22:53

When you build, I use (for borland)

bjam -sTOOLS="borland" -sBUILD="<threading>multi"

or something like that, haven't done it since the 1.30.0 release.  It 
definitely defaults to single threaded for borland for all libraries bar 
  boost::thread

I like the regex way of building and plan to introduce my own here so 
that I append mt/st to the .lib file name and link against the correct 
version with #pragma statements.

The other problem I've found (and we discussed before) was the build 
settings (alignment etc).  boost has default settings for all compilers 
and these may be different from your project options.  (we tend to build 
with 4-byte alignment rather than 8 but boost defaults to 8).  This also 
causes problems because of inlined code/.lib code in the same project.

I've wrapped all the boost headers (that I use) in a directory called 
boost_wrappers that first include a push header file to push all the 
boost options for the compiler, then include the boost header, then a 
pop header to pop the options back to the correct project settings.

We did discuss a while back about getting these push pragmas at the 
start and end of each header but there doesn't seem to be much support 
for it.  Without it, or without doing your own (as I have) you can't 
change or project options (or some of them) without re-building boost 
with those same options which is a PITA.

As an extra, I've built both debug and non-debug versions and appended a 
d to the debug files so I can #define DEBUG_BOOST_XXXXX to link with the 
debug version of the library and step through the code which can be 
quite handy.

Cheers

Russell

Ken Alverson wrote:
> 
> Certainly a possibility...this is the first time I've tried using a non
> header-based boost component.  However, I thought the boost config defaulted
> to thread support.  I certainly didn't do anything special to enable
> multithreading support on boost.  (and my application is statically linked to
> the multithreaded runtime)
> 
> Is there a document somewhere describing how to select which runtime boost
> will be built against?
> 
> Ken
>