On 08.12.2017 21:32, Tom Kent via Boost wrote:
On Fri, Dec 8, 2017 at 8:28 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
On 08.12.2017 08:32, Tom Kent via Boost wrote:
On Fri, Dec 8, 2017 at 6:10 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
Hello,
I'd like to report again an issue with the Windows binary packages that is still present with the 1.66.0 release (candidate). The issue is reported to the Boost.Python bug tracker at https://github.com/boostorg/python/issues/129, though I don't think I can address it there. In the Windows binary package the libboost_python3 library is built against (and links with) python2. I can't reproduce this myself when building Boost the normal way, and I don't know who owns the logic for building Windows binary packages. It doesn't seem to have its own repo / issue tracker. The fix might thus affect some piece of code that isn't itself part of the release. But it would be great if someone could look into it soon anyhow. :-)
I've got the logic for the windows builds here: https://github.com/teeks99/boost-release-windows/
I'm baffled by why this is happening. I'm including both python 2 and 3 paths in user-config.jam: https://github.com/teeks99/boost-release-windows/blob/master /user-config.jam.template Is there anything else I should be doing for the python build? I managed to reproduce the problem on Linux (not quite the same, as on Linux Boost.Python isn't linked to the Python library, but the problem is there nonetheless). I reported my findings to https://lists.boost.org/boost-build/2017/12/29715.php. In a nutshell, the problem is that the Boost.Build logic doesn't create a build tree layout that contains the Python version as a path component. As a consequence, it mistakenly reuses object files compiled with the previous Python version when linking Boost.Python libraries for subsequent Python versions.
The real fix (arguably to Boost.Build) is quite involved, and may be too late for the upcoming release. It might be better to consider changing the build script to invoke `b2` multiple times (once per Python version), and then package the libraries together, so the end result will look the same.
That sounds tricky.
Does that mean that I'd need to modify my user-config.jam file between the two builds? (I.e. only have one version of python in there at a time?)
I believe so, yes (though would prefer someone like Steven or Rene as the real experts to confirm the whole issue, as I may miss something).
I'm not sure I have the time to put in script changes for this before the next release. Instead, I think I'll just disable python3 (i.e. remove it from user-config.jam) so the windows build will only support python2. It is kinda a toss-up as to py2 vs. py3, the python community is definitely shifting away from py2 (end of life in 2020), but if there are users who have been building with the windows builds in the past, it was only working for py2 so I don't want to break that.
Right, I agree with that assessment & strategy. Stefan -- ...ich hab' noch einen Koffer in Berlin...