Bug 660980 – dev-util/cmake-3.11.4 - lots of packages fail with: CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:2044 (message): Unable to find the requested Boost libraries. Could not find the following Boost libraries: boost_python

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Dennis Schridde 2018-07-12 06:07:19 UTC]

Lots of packages fail with a message similar to:

CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:2044 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.65.0

  Boost include path: /usr/include

  Could not find the following Boost libraries:

          boost_python

  No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR to the
  directory containing Boost libraries or BOOST_ROOT to the location of
  Boost.


The likely cause being that cmake-3.8.0_rc2-FindBoost-python.patch was removed from dev-util/cmake-3.11, probably because upstream commit [1] claims to add support for such cases.  What was overlooked is that the logic it adds is special-cased and only applies to Boost >=1.67.

[1]: https://gitlab.kitware.com/cmake/cmake/commit/1673923c303c6a4184904c4c5849911feddb87e7

[Comment 1 Dennis Schridde 2018-07-12 18:50:37 UTC]

Created attachment 539324 [details, diff]
cmake-3.11.4-fix-boost-detection.patch

Actually the previous assertion was wrong, the support is not version specific.  I now rather think the issue is that Gentoo uses -python-X.Y library suffixes, while CMake checks for -python-XY only:
    # Gentoo
    list(APPEND _Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT_NAME "${COMPONENT_UNVERSIONED}-${COMPONENT_PYTHON_VERSION_MAJOR}${COMPONENT_PYTHON_VERSION_MINOR}")

This should be:
    # Gentoo
    list(APPEND _Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT_NAME "${COMPONENT_UNVERSIONED}-${COMPONENT_PYTHON_VERSION_MAJOR}.${COMPONENT_PYTHON_VERSION_MINOR}")

Attached patch fixes this.

Additionally this behaviour needs to be explicitly triggered by the packages -- i.e. they need to request the pythonXY component of boost.  I provide an example in the patch attached to bug #652266.

[Comment 2 Larry the Git Cow 2018-07-19 09:33:32 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d887fb4bc7efa2a3d4ad58f8a153ade5bc40b8d1

commit d887fb4bc7efa2a3d4ad58f8a153ade5bc40b8d1
Author:     Lars Wendler <[e-mail]>
AuthorDate: 2018-07-19 09:30:07 +0000
Commit:     Lars Wendler <[e-mail]>
CommitDate: 2018-07-19 09:33:24 +0000

    dev-util/cmake: Bump to version 3.12.0. Removed old.
    
    Added boost detection fix patch.
    
    Bug: https://bugs.gentoo.org/660980
    Package-Manager: Portage-2.3.43, Repoman-2.3.10

 dev-util/cmake/Manifest                                     |  2 +-
 .../cmake/{cmake-3.12.0_rc3.ebuild => cmake-3.12.0.ebuild}  |  7 +++++--
 dev-util/cmake/files/cmake-3.11.4-fix-boost-detection.patch | 13 +++++++++++++
 3 files changed, 19 insertions(+), 3 deletions(-)

[Comment 3 Lars Wendler (Polynomial-C) (RETIRED) 2018-07-19 09:34:09 UTC]

Please test and report back if that fixes the issue.

[Comment 4 Dennis Schridde 2018-07-20 22:00:22 UTC]

Fixes the issue for the case I reported when used in conjunction with the patch attached to bug #652266.

[Comment 5 Larry the Git Cow 2018-07-23 14:14:12 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=705548a43869f859770da2c388ba16a72468e2c6

commit 705548a43869f859770da2c388ba16a72468e2c6
Author:     Lars Wendler <[e-mail]>
AuthorDate: 2018-07-23 14:13:50 +0000
Commit:     Lars Wendler <[e-mail]>
CommitDate: 2018-07-23 14:14:05 +0000

    dev-util/cmake: Fix boost detection in 3.11.4 as well
    
    Bug: https://bugs.gentoo.org/660980
    Package-Manager: Portage-2.3.43, Repoman-2.3.10

 dev-util/cmake/{cmake-3.11.4.ebuild => cmake-3.11.4-r1.ebuild} | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

[Comment 6 Alexis Ballier 2018-08-02 11:28:33 UTC]

Still fails here. See bug #655836

[Comment 7 Torsten Kaiser 2018-08-18 13:45:40 UTC]

I just retried games-strategy/freeorion-0.4.7.1-r4 and this still fails with both dev-util/cmake-3.11.4-r1 and dev-util/cmake-3.12.1.
After downgrading to dev-util/cmake-3.10.3 the build of freeorion worked.

Downgrading to 3.10.3 did not work straight forward: With dev-libs/libuv-1.21.0-r1, -1.22.0 or -1.23.0 the older cmake did not find the system libuv and failed to build. Should the RDEPEND in cmake-3.10.3.ebuild changed to <dev-libs/libuv-1.21? I did not try if files/cmake-3.11.4-libuv-1.21.patch would help 3.10.

Both fixed dependent bugs (bug #652266 -> https://gitweb.gentoo.org/repo/gentoo.git/tree/media-gfx/openvdb/files/openvdb-4.0.2-findboost-fix.patch?id=74320c01dacb7c27d6901caac7ef67e47f0114e7 and bug #654326 -> https://gitweb.gentoo.org/repo/gentoo.git/tree/app-office/ledger/files/ledger-3.1.1-r1-boost-python.patch?id=2642ca2a2e080d478b417a37edd1500cf1c283fd ) modified their build system, so it does not seem to be fixed from the cmake side.

[Comment 8 Victor Mataré 2018-10-03 22:56:04 UTC]

I'd be fine simply upgrading to boost-1.67 if that fixes it. Any particular reason that's not yet keyworded?

[Comment 9 Victor Mataré 2018-10-03 23:46:23 UTC]

I just tried upgrading to boost-1.67 and that doesn't really change anything. I'm not sure if completely unversioned usage like this is even supposed to work:

find_package(Boost REQUIRED python)

From the regexes in the code it looks like FindBoost.cmake expects at least the major version, so it must be either python2 or python2.7.

However, it also doesn't work with python2 OR python2.7 since that results in the following find_library call (taken from a trace output):

/usr/share/cmake/Modules/FindBoost.cmake(383):  find_library(Boost_PYTHON2_LIBRARY_DEBUG NAMES;boost_python2-gcc73-mt-d-1_67;boost_python2-gcc73-mt-d;boost_python2-mt-d-1_67;boost_python2-mt-d;boost_python2-mt;boost_python2;boost_python2-gcc73-mt-d-1_67;boost_python2-gcc73-mt-d;boost_python2-mt-d-1_67;boost_python2-mt-d;boost_python2-mt;boost_python2;HINTS;/usr/lib;NO_DEFAULT_PATH;NO_CMAKE_FIND_ROOT_PATH;NAMES_PER_DIR;DOC;Boost python2 library (debug) )

Note that we end up looking for libboost-python2.7.so in /usr/lib, which is pretty close, but our libs are called libboost_python-2.7.so.

Don't know if the dash is some gentoo-specific quirk or whether cmake is going wrong here. If I change it to find_package(Boost REQUIRED python-2.7), it does find the lib, but then other things break:

CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:1727 (message):
  No header defined for python-2.7; skipping header check
Call Stack (most recent call first):
  CMakeLists.txt:9 (find_package)

So what exactly needs fixing here?

[Comment 10 Rolf Eike Beer 2018-12-30 16:06:47 UTC]

Reported upstream. Please don't just patch these things downstream, that just causes extra work.

[Comment 11 Rolf Eike Beer 2019-04-16 17:38:48 UTC]

Please test if https://gitlab.kitware.com/cmake/cmake/commit/0b54f72e940503adfbd978d7f1dedc3da4799f52 fixes the issue.

[Comment 12 Larry the Git Cow 2019-04-23 09:01:54 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=17269074d97f7ba56b5a8188461b00e4964fc8c9

commit 17269074d97f7ba56b5a8188461b00e4964fc8c9
Author:     Lars Wendler <[e-mail]>
AuthorDate: 2019-04-23 08:47:31 +0000
Commit:     Lars Wendler <[e-mail]>
CommitDate: 2019-04-23 09:01:47 +0000

    dev-util/cmake: Bump to version 3.14.3
    
    - including new upstream boost detection code
    - EAPI-7 bump
    
    Bug: https://bugs.gentoo.org/660980
    Package-Manager: Portage-2.3.64, Repoman-2.3.12
    Signed-off-by: Lars Wendler <[e-mail]>

 dev-util/cmake/Manifest            |   1 +
 dev-util/cmake/cmake-3.14.3.ebuild | 223 +++++++++++++++++++++++++++++++++++++
 2 files changed, 224 insertions(+)

[Comment 13 Michael Palimaka (kensington) 2019-04-25 02:43:54 UTC]

3.14.3 doesn't resolve any error for me

[Comment 14 Michael Palimaka (kensington) 2019-04-25 03:03:35 UTC]

Actually, according to FindBoost.cmake:
> Note that Boost Python components require a Python version suffix
> (Boost 1.67 and later), e.g. ``python36`` or ``python27`` for the
> versions built against Python 3.6 and 2.7, respectively.  This also
> applies to additional components using Python including
> ``mpi_python`` and ``numpy``.  Earlier Boost releases may use
> distribution-specific suffixes such as ``2``, ``3`` or ``2.7``.
> These may also be used as suffixes, but note that they are not
> portable.

So, I think the remaining blockers of this bug need to actually need patching to call FindBoost correctly, and should now block bug #668020 instead.