From: John Maddock (john_at_[hidden])
Date: 2006-08-21 05:49:46
Zack Weinberg wrote:
> Thread support can be turned off at build time, but there is no
> upstream support for installing thread-safe and non-thread-safe
> variants of the library (unlike in Boost) so I doubt packagers will
> want to mess with that. It doesn't use threads internally, so I
> _might_ be able to do the same trickery that is done in the C++
> runtime to stub out thread support at runtime when it's not needed,
> but I'd prefer the solution in Boost as this removes more overhead
> (the ICU libs wouldn't be loaded at all when they're not used).
Let me try and get this clear in my head, 'cos I'm still confused :-)
Boost.Regex is being built single threaded, but it's being linked to ICU
which then pulls in pthreads?
Just so you know: when Boost.Regex is built with BOOST_HAS_THREADS then it
pulls in pthreads as well, and for recent versions of gcc, BOOST_HAS_THREADS
is pretty much always defined (unless you take expicit steps to turn it off
with BOOST_DISABLE_THREADS). The "single-threaded" bjam builds aren't
really single threaded at all: they're more like "give me whatever the
compiler does by default".
What would happen if in addition to an all-in-one libboost_regex there were
separate mini-libs for the various parts, and the user could choose which
path they wanted to go down (figure out which bits they require and link to
them, or just grab the lot).
I'm not saying this extra build option could be implemented really fast: the
Win32 linking dll import/export would need to be split up, and it's not a
completely trivial task :-(
And finally, can you statically link to Boost.Regex? That would be a
simple-ish workaround that would only pull in what you actually use?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk