Ubuntu
boost1.71 package

Boost 1.71 missing python3/numpy3 symlinks

Bug #1865209 reported by Mike Purvis on 2020-02-28

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	boost1.71 (Ubuntu)	New	Undecided	Unassigned

Bug Description

As of Boost 1.71, the exact version of python is coded into the library name:

    $ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
    /usr/lib/x86_64-linux-gnu/libboost_numpy38.so
    /usr/lib/x86_64-linux-gnu/libboost_python38.so

This is pretty inconvenient compared to previous releases where there were generic symlinks, for example on Bionic with Boost 1.65:

    $ ls -1 /usr/lib/x86_64-linux-gnu/libboost_*py*.so
    /usr/lib/x86_64-linux-gnu/libboost_mpi_python3-py36.so
    /usr/lib/x86_64-linux-gnu/libboost_mpi_python3.so
    /usr/lib/x86_64-linux-gnu/libboost_mpi_python-py27.so
    /usr/lib/x86_64-linux-gnu/libboost_mpi_python-py36.so
    /usr/lib/x86_64-linux-gnu/libboost_mpi_python.so
    /usr/lib/x86_64-linux-gnu/libboost_numpy3-py36.so
    /usr/lib/x86_64-linux-gnu/libboost_numpy3.so
    /usr/lib/x86_64-linux-gnu/libboost_numpy-py27.so
    /usr/lib/x86_64-linux-gnu/libboost_numpy.so
    /usr/lib/x86_64-linux-gnu/libboost_python3-py36.so
    /usr/lib/x86_64-linux-gnu/libboost_python3.so
    /usr/lib/x86_64-linux-gnu/libboost_python-py27.so
    /usr/lib/x86_64-linux-gnu/libboost_python-py36.so
    /usr/lib/x86_64-linux-gnu/libboost_python.so

So that you could just -lboost_python3 (or numpy3) and it would do the right thing for the system's default versions.

Are there plans to fix this before release? I would expect that a lot of software would have been relying on the previous behaviour, especially CMake-using packages which were previously able to just:

find_package(Boost COMPONENTS python3)

But will now need to:

find_package(PythonInterp REQUIRED)
find_package(Boost COMPONENTS python${PYTHON_VERSION_MAJOR}${PYTHON_VERSION_MINOR})

And the above logic doesn't even work with the naming scheme used with Bionic, so the situation is even worse if you're trying to support multiple Ubuntu LTSes from the same codebase!

Ticket/discussion about this with upstream: https://github.com/boostorg/boost_install/issues/31

See original description

Mike Purvis (mikepurvis) on 2020-02-28

description:

updated

Revision history for this message

Mike Purvis (mikepurvis) wrote on 2020-02-28:

Having looked into this a bit further, it appears the new hotness is that this is actually being handled in the Boost-shipped CMake module:

/usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake

From my read of that, the expectation *now* is that you just do:

find_package(Boost COMPONENTS python)

And it does the right thing. But of course this approach breaks any package which was intentionally using "python3" in previous releases, or building libraries for both Python 2 and 3. In summary, these are how to link to boost_python over the past four years:

    1. find_package(Boost COMPONENTS python)
    2. find_package(Boost COMPONENTS python-pyXY)
    3. find_package(Boost COMPONENTS pythonX)
    4. find_package(Boost COMPONENTS pythonX-pyXY)
    5. find_package(Boost COMPONENTS pythonXY)

Xenial was 1 and 2. Bionic was 1, 2, 3, and 4. Focal is now 1 and 5, but 1 is now Python 3 instead of 2.

This is insane.

Mike Purvis (mikepurvis) on 2020-02-29

description:

updated

Revision history for this message

Mike Purvis (mikepurvis) wrote on 2020-03-08:

Upstream has now merged the change to support python3 as a component. This will release in Boost 1.73, but it's a small patch and should be possible to backport to 1.71:

https://github.com/boostorg/boost_install/commit/7d2b3bf3a25ecce33e256370e47d776d75685f7e