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

From: John Maddock (john_at_[hidden])
Date: 2006-08-22 06:17:30

Zack Weinberg wrote:
> Well, I don't know exactly how Debian's packages build Boost, but only
> the -mt- variants of other Boost shared libraries reference
> libpthread:

Because they don't have to do anything to be thread safe: regex has some 
global data whose initialisation is guarded by a mutex.  If 
BOOST_HAS_THREADS is defined then you'll end up linking to the pthreads 
code - or at least I think you will - it could be that it'll link to the 
libc stubs you talk about, maybe you could actually try a build without ICU 
suppport and see if it really makes the difference you think it will?

>> 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 sure I understand the difference between this and what I'm
> proposing ... is it just that in your plan, library users have to
> explicitly choose to link against the mini-libraries?  I guess I'd be
> fine with that given that nobody seems to be stepping up to the plate
> on the bjam magic, but wouldn't it have to wait for 1.34?

Um, it's a new feature, it would have to wait for 1.35 now I'm afraid since 
1.34 is already branched for release.

>> 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 :-(
>
> I don't know anything about the issues there, but I can believe it.
>
>> 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?
>
> We'd rather not do that; we already get enough grief from system
> integrators over all the _other_ (non-Boost) libraries we link
> statically.  [Y'all deserve some praise for delivering libraries that
> are reliable enough that we don't need local patches.]

Understood, pity though.

John.