checking whether x86_64-pc-linux-gnu-g++ supports C++11 features with -std=c++11... yes checking whether the Boost::System library is available... yes configure: error: Could not find a version of the Boost::System library! !!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-libs/libtorrent-rasterbar-1.2.11/work/libtorrent-1.2.11/config.log ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no-multilib_hardened-20210123-231458 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-10.2.0 * clang version 11.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/11/bin /usr/lib/llvm/11 11.0.1 Python 3.8.7 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) * Available Rust versions: [1] rust-1.48.0 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.272_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.8.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Thu Jan 28 23:33:03 UTC 2021 emerge -qpvO net-libs/libtorrent-rasterbar [ebuild N ] net-libs/libtorrent-rasterbar-1.2.11 USE="dht ssl -debug -doc -examples -libressl -python -static-libs -test" PYTHON_TARGETS="python3_8 -python3_7 -python3_9"
Created attachment 685056 [details] emerge-info.txt
Created attachment 685059 [details] emerge-history.txt
Created attachment 685062 [details] environment
Created attachment 685065 [details] etc.portage.tar.bz2
Created attachment 685068 [details] logs.tar.bz2
Created attachment 685071 [details] net-libs:libtorrent-rasterbar-1.2.11:20210129-005025.log
Created attachment 685074 [details] temp.tar.bz2
Did some trivial breakage happen? I was going to stabilize that version and tested against all the available boost versions, everything went fine so far...
*** Bug 775038 has been marked as a duplicate of this bug. ***
This appears to be caused by libboost_system-mt at line 17855 of the configure script. It does an ls and finds libboost_system as well as libboost_system-mt, and gets an error when it gets around to trying libboost_system-mt. We would need to modify to exclude this file from the checking in the configure script(s). Hacking these scripts on my system has allowed it to configure and compile. I am not experienced in configure scripts to know the best way of correcting this. For python I did have to add 'BOOST_BUILD_PATH="/usr/share/boost-build/"' as an environment variable.
Problem configure in option --with-boost=/usr It is worked: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/libtorrent-rasterbar-1.2.12 --htmldir=/usr/share/doc/libtorrent-rasterbar-1.2.12/html --with-sysroot=/ --libdir=/usr/lib64 --disable-debug --disable-export-all --disable-logging --enable-dht --disable-examples --enable-encryption --disable-static --disable-tests --with-libiconv --enable-logging
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b3c6afa4d9c2dba2bded8b0e25bdbd9f6fe3b118 commit b3c6afa4d9c2dba2bded8b0e25bdbd9f6fe3b118 Author: Alan Swanson <reiver@improbability.net> AuthorDate: 2021-06-07 08:20:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-27 00:26:06 +0000 net-libs/libtorrent-rasterbar: Version bump (v1.2.14) Signed-off-by: Alan Swanson <reiver@improbability.net> Closes: https://bugs.gentoo.org/767835 Closes: https://github.com/gentoo/gentoo/pull/20850 Signed-off-by: Sam James <sam@gentoo.org> net-libs/libtorrent-rasterbar/Manifest | 1 + .../libtorrent-rasterbar-1.2.14.ebuild | 112 +++++++++++++++++++++ 2 files changed, 113 insertions(+)
Exactly same failure with net-libs/libtorrent-rasterbar-1.2.14 (emerge --sync 6-oct-2021). Side note - if I run ./configure with parameters present in build.log via command line (in /build directory) it passes successfully, but long term that's not a way to go.
Created attachment 744474 [details] logs requested when bug during emerge happens
What is the version of boost you're running? And is your system fully updated? I cannot reproduce your issue, it just work here.
In my system boost 1.76.0 is installed: # equery l boost * Searching for boost ... [IP-] [ ] dev-libs/boost-1.76.0-r1:0/1.76.0 I believe system is fully updated. At least emerge -1auD --verbose-conflicts --keep-going -j8 @world emerge -1aD --verbose-conflicts --keep-going -j8 @preserved-rebuild emerge --depclean completed successfully. > I cannot reproduce your issue, it just work here. The worst type of bugs is one hard to reproduce. I believe something is wrong with env - pay attention, that same ./configure passes successfully when started not from emerge but from plane command line. I'll be away for 2 weeks, starting with 27 of October I'll be glad to run on my problematic box anything needed to help reproducing an issue.
To be precise - mentioned error first took place during world emerge. I had to remove the library and qbittorrent in order to complete update. When system got fully updated I wanted to install torrent again - but failed.
(In reply to Alexander Peshkov from comment #14) > Created attachment 744474 [details] > logs requested when bug during emerge happens Could you include this too? >!!! Please attach the following file when seeking support: >!!! /var/tmp/portage/net-libs/libtorrent-rasterbar-1.2.14/work/libtorrent-1.2.14/config.log
(In reply to Alexander Peshkov from comment #13) > Exactly same failure with net-libs/libtorrent-rasterbar-1.2.14 (emerge > --sync 6-oct-2021). > > Side note - if I run ./configure with parameters present in build.log via > command line (in /build directory) it passes successfully, but long term > that's not a way to go. Can you attach full output of such configure call to this bug, the working one? Like ./configure [whatever params you added] 2>&1 | tee -a /tmp/configure.log I am interested in what it said and where it found boost there.
Created attachment 744747 [details] Requested logs and working patch After reboot I've failed to reproduce successful run of ./configure from command line. But due to easy reproduced failure I've found a reason of it - incorrect value of BOOST_LDFLAGS=-L/usr/lib/x86_64-linux-gnu, on my box there is such directory but boost libraries are located in /usr/lib64. That made possible trivial patch that helped me finish with emerge (patch in tgz archive). It's definitely not generally useful, just an illustration for you. I've attached needed to you logs but suppose reason of failure is almost clear - when searching for liboost* path a case when liboost* libraries are located in system lib directory and therefore available w/o additional -L flag should be checked first.
(In reply to Alexander Peshkov from comment #20) > Created attachment 744747 [details] > Requested logs and working patch > > After reboot I've failed to reproduce successful run of ./configure from > command line. > > But due to easy reproduced failure I've found a reason of it - incorrect > value of BOOST_LDFLAGS=-L/usr/lib/x86_64-linux-gnu, on my box there is such > directory but boost libraries are located in /usr/lib64. That made possible > trivial patch that helped me finish with emerge (patch in tgz archive). It's > definitely not generally useful, just an illustration for you. > Ah. Why does such a directory exist for you? Anyway, I've reproduced the bug if I mkdir it. AX_BOOST_BASE has --with-boost-libdir which we can pass to override this detection (it thinks you're on Debian): https://github.com/arvidn/libtorrent/blob/RC_1_2/m4/ax_boost_base.m4#L121. Thanks!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff6cb86226cec4ee21db00dbbd7e10c3764a61c7 commit ff6cb86226cec4ee21db00dbbd7e10c3764a61c7 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-31 04:42:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-31 04:42:50 +0000 net-libs/libtorrent-rasterbar: fix finding Boost in some cases AX_BOOST_BASE may be misled if some errant directories exist, like /usr/lib/x86_64-linux-gnu (thinking we're on Debian). Closes: https://bugs.gentoo.org/767835 Signed-off-by: Sam James <sam@gentoo.org> net-libs/libtorrent-rasterbar/libtorrent-rasterbar-1.2.14-r1.ebuild | 2 ++ 1 file changed, 2 insertions(+)
