Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1

Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1
From: Tom Kent (lists_at_[hidden])
Date: 2017-12-09 02:32:26

On Fri, Dec 8, 2017 at 8:28 AM, Stefan Seefeld via Boost <
boost_at_[hidden]> 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_at_[hidden]> 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'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.

Tom