USE="python" PYTHON_TARGETS="python3_9" dev-libs/boost does not build /usr/lib64/libboost_python39.so.1.78.0 ergo cannot build net-libs/libtorrent-rasterbar net-libs/libtorrent-rasterbar is looking for libboost_python39.so.1.78.0 but does not exist. equery f dev-libs/boost | grep "boost_python39.so.1.78.0" -> empty equery f dev-libs/boost | grep "boost_python39.so.1.77.0" -> exists I ran `emerge -1v =dev-libs/boost-1.78.0` but still, only a 1.77.0 python library.
Sam James, you're pretty active and quick here. Thank you for adjusting the report!
Confirmed on my system, same error
adding the "numpy" use flag to boost was able to build the "libboost_python39.so.1.78.0" file so should be able to build rasterbar now
(In reply to Chris Faulkner from comment #3) > adding the "numpy" use flag to boost was able to build the > "libboost_python39.so.1.78.0" file so should be able to build rasterbar now Thank you for helping the devs out!
(In reply to Alec Ari from comment #1) > Sam James, you're pretty active and quick here. Thank you for adjusting the > report! Thanks a lot! (In reply to Chris Faulkner from comment #3) > adding the "numpy" use flag to boost was able to build the > "libboost_python39.so.1.78.0" file so should be able to build rasterbar now Wow, that's interesting... I can't promise I can poke at this tonight given I'm absolutely not an expert (and rather scared) regarding bjam/jam/whatever Boost's build system is. soap is aware of the bug anyway and is going to speak to upstream if necessary.
(In reply to Alec Ari from comment #4) > (In reply to Chris Faulkner from comment #3) > > adding the "numpy" use flag to boost was able to build the > > "libboost_python39.so.1.78.0" file so should be able to build rasterbar now > > Thank you for helping the devs out! NP, I'm just wondering if "numpy" should be in the USE statement or not. I think it's probably just an ebuild thing that can get sorted out in the upstream.
soap spoke to upstream and got https://github.com/bfgroup/b2/pull/113. Will look at it later.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5fb9ee5a02b6a0aa39fea12b0682838b3feee8ac commit 5fb9ee5a02b6a0aa39fea12b0682838b3feee8ac Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-14 23:28:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-14 23:29:47 +0000 dev-libs/boost: require patched boost-build for 1.78 (fix Python bindings) BDEPEND on a newer, patched boost-build which fixes installation of Python bindings for us. Obviously reinstallation of Boost is necessary with the fixed build system hence revbump. Closes: https://bugs.gentoo.org/829031 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/boost/{boost-1.78.0.ebuild => boost-1.78.0-r1.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77c372e1669cd6250aa6e0b0b0888be02595fe64 commit 77c372e1669cd6250aa6e0b0b0888be02595fe64 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-14 23:28:15 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-14 23:29:46 +0000 dev-util/boost-build: fix incorrectly skipping targets (upstream fix) Fixes installation of Boost 1.78's Python bindings. Closes: https://bugs.gentoo.org/829031 Signed-off-by: Sam James <sam@gentoo.org> ...ld-1.78.0.ebuild => boost-build-1.78.0-r1.ebuild} | 1 + ...oost-build-1.78.0-fix-python-bindings-build.patch | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+)
emerge -1av dev-libs/boos with portage 3.0.30 does not schedule dev-util/boost-build update
(In reply to Eugene Shalygin from comment #9) > emerge -1av dev-libs/boos with portage 3.0.30 does not schedule > dev-util/boost-build update Try --deep? I'm not sure why it wouldn't? What does a world update do? There shouldn't be a need to manually re-emerge Boost here.
MAJOR_V is probably "1.78" for this version and BDEPEND is incorrectly set then: -BDEPEND=">=dev-util/boost-build-${MAJOR_V}-r1" +BDEPEND=">=dev-util/boost-build-${PV}-r1" With PV it pulls in dev-util/boost-build as it should.
(In reply to Eugene Shalygin from comment #11) > With PV it pulls in dev-util/boost-build as it should. Or, perhaps, +BDEPEND=">=dev-util/boost-build-${MAJOR_V}.0-r1"
(In reply to Eugene Shalygin from comment #12) > (In reply to Eugene Shalygin from comment #11) > > With PV it pulls in dev-util/boost-build as it should. > > Or, perhaps, > +BDEPEND=">=dev-util/boost-build-${MAJOR_V}.0-r1" huh, thanks. I'll just hardcode it because it doesn't make sense to do -r1 in future anyway.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fab14b91a202b5651b02f5aca6abaca813687f15 commit fab14b91a202b5651b02f5aca6abaca813687f15 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-12-15 01:28:16 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-12-15 01:28:16 +0000 dev-libs/boost: fix BDEPEND lower bound for boost-build Closes: https://bugs.gentoo.org/829031 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/boost/{boost-1.78.0-r1.ebuild => boost-1.78.0-r2.ebuild} | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Thank you!
(In reply to Eugene Shalygin from comment #15) > Thank you! Thank you!
