git commit a514c2b395994d added -std=cxx14 to libtorrent-rasterbar, presumably in order to fix a build problem with qbittorrent. Expecting nothing but problemss, I rebuilt my working installation of libtorrent-1.2.9, and you won't believe what happened next: Deluge refuses to start with several meters of unhelpful python import errors because libtorrent's own Python module no longer loads, and an error cascade ensues. Temporarily removing the added std=c++14 and rebuilding immediately makes libtorrent work again. I briefly suspected boost or its python support, but it already uses C++14 by default and so could not be the problem. Reproducible: Always Steps to Reproduce: 1. emerge libtorrent-rasterbar-1.2.9 2. run python3.8 -c "import libtorrent" 3. kaput! Actual Results: $python3.8 -c "import libtorrent" Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: /usr/lib/python3.8/site-packages/libtorrent.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZNK10libtorrent5entry4dictEv Expected Results: Working import. Indeed the expected symbol is not in libtorrent's shared library: $strings /usr/lib64/libtorrent-rasterbar.so.10.0.0 | grep _ZNK10libtorrent5entry4dict _ZNK10libtorrent5entry4dictB5cxx11Ev It looks like there is a C++11 entry point, but somehow that's not the expected one. No idea what's going on here, but it looks like the python module is being built with -std=c++11 ABI.
We have a Bingo! When building libtorrent-rasterbar in verbose mode we can find that the python module is being built like this: ... x86_64-pc-linux-gnu-g++ -pipe -march=native -O2 -std=c++14 -fPIC -I/tmp/portage/net-libs/libtorrent-rasterbar-1.2.9/work/libtorrent-libtorrent-1.2.9/src/include -I../../include -I/usr/include -I/usr/include -I/usr/include/python3.8 -c /tmp/portage/net-libs/libtorrent-rasterbar-1.2.9/work/libtorrent-libtorrent-1.2.9-python3_8/bindings/python/src/alert.cpp -o /tmp/portage/net-libs/libtorrent-rasterbar-1.2.9/work/libtorrent-libtorrent-1.2.9-python3_8/build/temp.linux-x86_64-3.8/tmp/portage/net-libs/libtorrent-rasterbar-1.2.9/work/libtorrent-libtorrent-1.2.9-python3_8/bindings/python/src/alert.o -DTORRENT_USE_OPENSSL -DTORRENT_USE_LIBCRYPTO -DBOOST_ASIO_HAS_STD_CHRONO=1 -DBOOST_EXCEPTION_DISABLE -DBOOST_ASIO_ENABLE_CANCELIO -DTORRENT_LINKING_SHARED -pipe -march=native -O2 -std=c++14 -ftemplate-depth=512 -Wno-format-zero-length -fvisibility=hidden -fvisibility-inlines-hidden -Wno-deprecated-declarations -g0 -Os -std=c++11 ... As in std=c++14 is correctly added along with my portage flags..and then artisinally overridden with -std=c++11, thus the python module's ABI won't match the shared lib ABI.
Running a plain './configure --enable-python-binding CFLAGS="-O -std=c++14" CXXFLAGS="-O -std=c++14"' & building libtorrent shows the same problem: lib is built with specified flags, python binding adds std=c++11 - indicating that this seems to be a problem with libtorrent's build system not properly propagating build flags to the module.
Apparently this is a problem-in-progress: https://github.com/arvidn/libtorrent/pull/5026
Created attachment 657564 [details, diff] Patch to remove unhelpful -std=c++11 specifier The mystery soup that is libtorrent's configure output generates several hardcoded references to -std=c++11; the one relevant for compiling the binding is in a file called 'bindings/python/compile_cmd' which contains "g++ -std=c++11". This terrible ad-hoc proof-of-concept patch results in a build with portage-enforced flags AND builds the python module without accidental C++11 ABI; Deluge works again. \o/
Qbittorrent also has the same problem as deluge, with an ld (link) error. Adding the patch to the libtorrent-rasterbar ebuild compiles fine, and qbittorrent also compiles against it now.
Don O beat me to it in comment #5. Since libtorrent-rasterbar updated to 1.2.9 a few days ago, I was using qbittorrent 4.2.5. Today, qbittorrent updated to -r2 and would not compile, bringing me here to this bug. Rolling back libtorrent to 1.2.6 allowed qbittorrent to compile, so now it is working with the previous libtorrent-rasterbar-1.2.6. I've masked 1.2.9 for now.
fixed in the repo.
Excuse me, apparently the fix is not working for me. Technically it is working as expected: ``` cat /var/tmp/portage/net-libs/libtorrent-rasterbar-1.2.10/work/libtorrent-libtorrent-1.2.10/bindings/python/compile_cmd x86_64-pc-linux-gnu-g++ ``` I tested `filter-flags -std=c++11` from flat-o-matic, didn't work. I don't know, I mess a lot with my flags, maybe it's my fault. However, this is my patch. I know it doesn't apply solely on python module, but here it is: ``` @@ -43,6 +43,7 @@ " src_prepare() { + sed -i -e 's,AX_CXX_COMPILE_STDCXX_11,AX_CXX_COMPILE_STDCXX_14,g' "${S}"/configure.ac || die mkdir -p "${S}"/build-aux || die touch "${S}"/build-aux/config.rpath || die append-cxxflags -std=c++14 ``` I haven't deleted other modifications from ebuild (compile_cmd,append-cxxflag) but they can be deleted as well. deluge daemon is working. qbittorrent is compiled. Best regards.
