bcp namespace aliasing broken, impacts package providers, shared libraries unusable since 1.69
Hi, I'd like to point out that bcp namespace aliasing has been broken for quite a while, which impacts package providers of Boost which choose to package it with a versioned namespace. We should try to fix to enable more people to upgrade. The bug has been reported March 2018 on trac https://svn.boost.org/trac10/ticket/13460 Then again by me this week on github https://github.com/boostorg/bcp/issues/4 Things have been made worse since 1.69 because libraries now build with visibility hidden by default, which means that with this bug symbols don't get exported and nothing links. Also I would argue that this set-up should be tested as part of the release validation process. The boost build system is arcane enough that we don't need a pretty standard build configuration to be subtly broken for more than a year. Could we try to address this before 1.71?
On 24/05/2019 09:58, Mathias Gaunard via Boost wrote:
Hi,
I'd like to point out that bcp namespace aliasing has been broken for quite a while, which impacts package providers of Boost which choose to package it with a versioned namespace. We should try to fix to enable more people to upgrade.
The bug has been reported March 2018 on trac https://svn.boost.org/trac10/ticket/13460 Then again by me this week on github https://github.com/boostorg/bcp/issues/4
I've seen the git issue but missed the earlier one, apologies for that.
Things have been made worse since 1.69 because libraries now build with visibility hidden by default, which means that with this bug symbols don't get exported and nothing links.
Also I would argue that this set-up should be tested as part of the release validation process. The boost build system is arcane enough that we don't need a pretty standard build configuration to be subtly broken for more than a year.
Could we try to address this before 1.71?
We can try, PR's would be welcome. Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Fri, 24 May 2019 at 18:01, John Maddock via Boost
We can try, PR's would be welcome.
The problem is that bcp is very crude about how it does things, so it's tightly coupled to what the Jamroot looks like at the time. It's easy enough to fix bcp right now by coming up with regex exceptions, but that's fragile. I don't know what's the best way to fix this. Extend boost build to be more aware of bcp, or just have better testing?
Mathias Gaunard wrote:
Hi,
I'd like to point out that bcp namespace aliasing has been broken for quite a while, which impacts package providers of Boost which choose to package it with a versioned namespace. We should try to fix to enable more people to upgrade.
The bug has been reported March 2018 on trac https://svn.boost.org/trac10/ticket/13460 Then again by me this week on github https://github.com/boostorg/bcp/issues/4
Your issue is a bit on the laconic side. You don't explain what the problem is, you don't explain how the problem can be reproduced, what is the scenario that breaks, how we can test it to be sure it's fixed, etc. I can guess that bcp --namespace=foo edits the line import tools/boost_install/boost-install ; into import tools/foo_install/boost-install ; and that it turns name = boost_$(name) ; autolink = <link>shared:<define>$(name:U)_DYN_LINK=1 ; into name = foo_$(name) ; autolink = <link>shared:<define>$(name:U)_DYN_LINK=1 ; which results in FOO_DYN_LINK=1 being defined. We can fix the latter by changing it to autolink = <link>shared:<define>BOOST_$(name:U)_DYN_LINK=1 ; name = boost_$(name) ; and we could in principle change the former to import tools/boost\_install/boost-install ; in order to hide it from bcp, although that's not very pretty. But as a first step I think that we need to add a Travis test to tools/bcp that exercises the scenario we want to fix. For which we probably need to know what it is.
participants (3)
-
John Maddock -
Mathias Gaunard -
Peter Dimov