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: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-12-09 02:36:51

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_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 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...