Re: [boost] Mixing different versions of Boost libs in a single process

Subject: Re: [boost] Mixing different versions of Boost libs in a single process
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-05-24 18:00:50

Grund, Holger wrote:
> 
> Well, BoostCon is over. So let me try again focusing on some specific
> bits:
>> 
>> So the next best thing would be the ability to mix different versions
>> of Boost in a single process. Today, linkage names will be identical
>> across versions, which is problematic for static libraries on Windows,
>> and static libs and DSOs on Linux.
> 
> [..]
>  
>> Also there's BCP, which supports renaming namespaces. That's great, but
>> I guess it could be even better -- e.g. on toolchains where we have
>> inline namespaces or __attribute__((strong)). On Linux targets, symbol
>> versioning via GNU LD version scripts might make things a bit better --
>> specifically, in that things gone wrong fail earlier and with better
>> diagnostics.
>> 
> So when I run BCP on the entire boost tree I still get linkage names that
> would seem to clash across versions. Specifically, there's the
> graphml_reader namespace in libs/graph/src/graphml.cpp.
> 
> Boost.Python and Boost.MPI have symbols that could cause problems, though
> these would seems to come from external OpenMPI and Python headers. I
> haven't really looked but it seems these should be fine so long as we
> build against the same OpenMPI and Python versions with the same
> configuration.
> 
> What's the policy here? Do we want BCP to address these things? Or do we
> want libraries to not use namespaces outside of ::boost (or use
> linkage/symbol visibility to hide symbols from other DSOs)?
> 

I expect the policy to be nothing outside boost, except for the external "C"
functions that must be prefixed by boost_. The rule could be relaxed to
namespaces prefixed by boost_ as this could be needed to avoid ADL.

I don't know how bcp manage with symbols with C linkage, but it seems rather
difficult to make the difference between the ones defined by boost and the
others without a prefix.

Are there any tools to detect this kind of problem? I have a few things
check two binaries for potential conflicts by walking debug info and symbol
tables -- it's far from perfect and I can't just upload this to Boost, but
I'd be happy to help out, if there's interest to get something into the
regression tests.

Not that I'm aware. It would be great if the inspection program could detect
this kind of naming issues. 

This test could also be added to the bcp tool, but I think that the tools
are not used in the regression tests now. 

I'm sure that if you could provide a Jamfile that test these possible
issues, the Boost community will find a way to include it in the regression
tests.

Thoughts, anyone?

I think the first thing you can do is to create Trac tickets for the issues
you have found.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Re-Mixing-different-versions-of-Boost-libs-in-a-single-process-tp3547777p3548342.html
Sent from the Boost - Dev mailing list archive at Nabble.com.