Re: [Boost-build] Splitting libboost_regex.so into ASCII and ICUsubmodules while preserving binary compatibility - need bjam help

From: Zack Weinberg (zackw_at_[hidden])
Date: 2006-08-20 13:46:34

On 8/20/06, John Maddock <john_at_[hidden]> wrote:
> I appreciate the problem (and have no idea how to accumplish that kind of
> cleverness in a Jamfile).
...
> So the problem is this: if ICU forces certain build requirements, those
> filter up to section (1) and then down to all the other parts: since (1) has
> to be binary compatible with all the others including the ICU part :-(

I admit to not having read the code very carefully, but I do not think
this is a problem.  I'm not suggesting that we change anything in the
way the code is *compiled*, only that one module (icu.cpp) be linked
into a separate shared object from the rest of the library.  All of
the references to the ICU libraries are in icu.cpp, and none of the
other modules in the library have references into icu.cpp (I checked
this by comparing symbol tables, but it also follows from the
observation that the only #ifdef BOOST_HAS_ICU in the library is in
icu.cpp, and if undefined, the file defines nothing).  Naturally, the
hypothetical libboost_regex_icu.so would need to depend on
libbost_regex_core.so, but that is easy to arrange (you just link it
with it)

> Even if you were to separate these out, would vendors really ship single
> threaded versions of the narrow and wide character parts?  What about folks
> who want to use those in a multithreaded environment?  There are certainly
> plenty of people doing so.

Debian at least does ship both single- and multithreaded variants of
all the boost libraries.

> Oh wait, reading over your post again, I see that you are using the
> supposedly non-thread safe version of the Boost lib's?  But these drag in
> the thread safe runtime anyway?

Yep.  This is only a problem with boost_regex; the thread library
dependency comes in by way of the ICU libs.

> If I've got this right, then one trick
> might be to not include ICU support in non-thread safe builds, and simply
> say "if you need ICU then you have to use the thread safe version".

That would not be an acceptable patch for (Debian's packages of)
1.33.x, as it would change the ABI of the existing single-threaded
libboost_regex.  It therefore doesn't solve my problem, sorry.

> Do you know if ICU always requires thread safety, or this also a packaging choice?

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).

zw