Public bug reported:

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!

** Affects: boost1.71 (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  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
+     $ 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
+     $ 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)
+     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})
+     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!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865209

Title:
  Boost 1.71 missing python3/numpy3 symlinks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/boost1.71/+bug/1865209/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to