Summary: | net-libs/libtorrent-rasterbar-2.0.3[python]: does not compile - fails to find boost python config | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Klemen Mihevc <solor> |
Component: | Current packages | Assignee: | Mikle Kolyada (RETIRED) <zlogene> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | axiator, crabbedhaloablution, dave.knippers, grozin, imatiimba, iordanov, jasmin+gentoo, michiel, sam, slashbeast, soap, susanw, tero, venerix, zueski |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
cmakeoutput.log if it helps cmakeerror.log |
Description
Klemen Mihevc
2021-05-30 12:49:18 UTC
Created attachment 712551 [details]
build.log
Created attachment 712554 [details]
cmakeoutput.log if it helps
Created attachment 712557 [details]
cmakeerror.log
emerge -pv boost boost-build? mih ~ # emerge -pv boost boost-build These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-util/boost-build-1.76.0-r2::gentoo USE="-examples" 0 KiB [ebuild R ] dev-libs/boost-1.76.0-r1:0/1.76.0::gentoo USE="bzip2 icu lzma nls python threads zlib zstd -context -debug -doc -mpi -numpy -static-libs -tools" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_9 -python3_7 -python3_8" 0 KiB boost and boost-build compile just fine, i also recompiled them but it doesnt fixes a problem. I confirm the problem. I have the same. I have the same problem as well, re-emerging boost-build and boost has no impact. Same issue. It looks like the Boost package creates: boost_python-config.cmake but not: boost_python3.9Config.cmake boost_python3.9-config.cmake which libtorrent-rasterbar is looking for. thor /usr/portage/dev-libs/boost # equery files boost | grep boost_python /usr/lib64/cmake/boost_python-1.76.0 /usr/lib64/cmake/boost_python-1.76.0/boost_python-config-version.cmake /usr/lib64/cmake/boost_python-1.76.0/boost_python-config.cmake /usr/lib64/cmake/boost_python-1.76.0/libboost_python-variant-shared-py3.8.cmake /usr/lib64/cmake/boost_python-1.76.0/libboost_python-variant-shared-py3.9.cmake /usr/lib64/libboost_python38-mt.so /usr/lib64/libboost_python38.so /usr/lib64/libboost_python38.so.1.76.0 /usr/lib64/libboost_python39-mt.so /usr/lib64/libboost_python39.so /usr/lib64/libboost_python39.so.1.75.0 /usr/lib64/libboost_python39.so.1.76.0 It seems like something should be fixed in the Boost package then? I was able to got this to compile and install with a temporary workaround. I haven't tried running anything yet that it depends on though. The workaround is in the source file directory of this package in bindings/python/CMakeLists.txt, change line 40 from: set(boost-python-module-name "python${Python3_VERSION_MAJOR}${Python3_VERSION_MINOR}" CACHE STRING "Boost::python module name, e.g. 'python-3.6'") to: set(boost-python-module-name "python") Then it would compile and install. I made a one liner change to /usr/lib64/cmake/Boost-1.76.0/BoostConfig.cmake on my boost local install at line 116 from: if("${comp}" MATCHES "^(python|numpy|mpi_python)([1-9])([0-9])$") to: if("${comp}" MATCHES "^(python|numpy|mpi_python)([1-9])\.?([0-9])$") libtorrent-rasterbar seems to be looking for boost_python3.9 but the cmake file checks for python39. I don't know what the "correct" python versions should be specified, but this fixed the configure phase, qbittorrent seems to work fine after rebuilding. A test with: if("${comp}" MATCHES "^(python|numpy|mpi_python)([1-9])\\.?([0-9])$") with double backslashes seem to work better, so non python components work. a new version 2.0.4 has been released Looks like the ebuild is ignoring the PYTHON_TARGET: [ebuild U ] net-libs/libtorrent-rasterbar-2.0.3-r1:0/2.0::gentoo [1.2.11:0/10::gentoo] USE="dht python ssl -debug -gnutls% -test (-doc%) (-examples%) (-libressl%) (-static-libs%)" PYTHON_TARGETS="(-python3_7%) (-python3_8%*) (-python3_9%)" 0 KiB even though make.conf definef (and all packages follow): PYTHON_TARGETS="python3_8" PYTHON_SINGLE_TARGET="python3_8" Does not work for me as well: emerge -pv net-libs/libtorrent-rasterbar --nodeps These are the packages that would be merged, in order: [ebuild U ~] net-libs/libtorrent-rasterbar-2.0.3-r1:0/2.0::gentoo [1.2.12-r1:0/10::gentoo] USE="dht python ssl -debug -gnutls% -test (-doc%) (-examples%) (-static-libs%)" PYTHON_TARGETS="(-python3_8%*) (-python3_9%*)" 4,194 KiB I have set */* PYTHON_TARGETS: python3_8 python3_9 */* PYTHON_SINGLE_TARGET: -* python3_8 in the package.use directory. I think it should not not be "(-python3_8%*)" therefore, and it isn't for other packages I emerge. Something is broken here I think but I don't understand what or why?!? I have this problem on all 4 of my systems. libtorrent-rasterbar versions 2.0.3 and 2.0.4 both fail on all four systems. I have not tried making a local copy of dev-libs/boost-1.76.0-r1 ( see commment #9 and comment #10 ) yet. On my latest, most clean build where I haven't installed qbittorrent, I tried various things involving python3_9/3_8 including an non-overridden profile. In my testing, I noticed 'eix' reported only a single version of dev-libs/boost is now available in the gentoo portage tree. This makes me reluctant to make a modified local copy of same since I'm not an actual programmer. Could someone post a 'patch' for dev-libs/boost I can try? Regarding my comment #14 - I forgot to note that <net-libs/libtorrent-rasterbar-2.0 compiles on all my systems. (In reply to Guy from comment #14) > I have this problem on all 4 of my systems. > > libtorrent-rasterbar versions 2.0.3 and 2.0.4 both fail on all four systems. > > I have not tried making a local copy of dev-libs/boost-1.76.0-r1 ( see > commment #9 and comment #10 ) yet. > > On my latest, most clean build where I haven't installed qbittorrent, I > tried various things involving python3_9/3_8 including an non-overridden > profile. > > In my testing, I noticed 'eix' reported only a single version of > dev-libs/boost is now available in the gentoo portage tree. This makes me > reluctant to make a modified local copy of same since I'm not an actual > programmer. > > Could someone post a 'patch' for dev-libs/boost I can try? At worst that modification can do is break boost for other applications that are using it. Also if something goes wrong you can always reemerge boost. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3a7fe6fe1c4f9593013363647c187266ff50a993 commit 3a7fe6fe1c4f9593013363647c187266ff50a993 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-27 01:08:00 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-27 01:10:27 +0000 net-libs/libtorrent-rasterbar: fix 2.0.x build with Boost (and fix Python eclass) - Fix Boost by using a different Python version name (drop the ., just like we did in previous versions) - Don't use python-any-r1, but python-single-r1 instead. python-any-r1 is for where we have a build-time *only* dependency, but we build libraries linked against libpython, so we need it at runtime too. - Fix other dependencies (everything is an RDEPEND too) Closes: https://bugs.gentoo.org/793038 Signed-off-by: Sam James <sam@gentoo.org> ...-r1.ebuild => libtorrent-rasterbar-2.0.4-r2.ebuild} | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=675412af4c3016387bbc9410b306aa2451c3536e commit 675412af4c3016387bbc9410b306aa2451c3536e Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-27 01:09:49 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-27 01:10:28 +0000 net-libs/libtorrent-rasterbar: drop 2.0.3-r2 Bug: https://bugs.gentoo.org/793038 Signed-off-by: Sam James <sam@gentoo.org> net-libs/libtorrent-rasterbar/Manifest | 1 - .../libtorrent-rasterbar-2.0.3-r2.ebuild | 54 ---------------------- 2 files changed, 55 deletions(-) You should all be able to revert your BoostConfig.cmake changes now (or just emerge -v1 boost) as I've changed the Python version format we pass to the build system. I've also fixed the eclass we use (see the commit message above) so PYTHON_TARGETS and such should be respected now. |