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-lib... Sent from the Boost - Dev mailing list archive at Nabble.com.