Re: [boost] Mixing different versions of Boost libs in a single process
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)? 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. Thoughts, anyone? Thanks! -hg -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.
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.
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.
Agreed, it's hard to by looking at the sources. But you can easily work out a lot of things from the binaries and debug information.
Not that I'm aware. It would be great if the inspection program could detect this kind of naming issues.
I guess, what I'd like to see is some effort to make sure that this use case is considered. I wouldn't be too surprised to learn that whoever put things in the graphml_reader namespace simply wasn't aware of the consequences for binary compatibility.
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 don't really insist on the regression tests. But some kind of mechanism to ensure the potential problems are raised would be great.
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.
That would be great. Let me see what I can come up with.
I think the first thing you can do is to create Trac tickets for the issues you have found.
Will do. Thanks! -hg -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.
participants (2)
-
Grund, Holger -
Vicente Botet