On Fri, Nov 27, 2020 at 02:21:04PM +0500, Andrey Rahmatullin wrote: > >>> import libtorrent > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ImportError: > /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux- > gnu.so: undefined symbol: _ZNK10libtorrent5entry4dictEv > > $ ldd -r /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux- > gnu.so | fgrep undefined | fgrep -v Py > undefined symbol: _ZNK10libtorrent5entry4dictEv (/usr/lib/python3/dist- > packages/libtorrent.cpython-39-x86_64-linux-gnu.so) > undefined symbol: _ZN10libtorrent5entry4dictEv (/usr/lib/python3/dist- > packages/libtorrent.cpython-39-x86_64-linux-gnu.so)
So far I see these interesting things: * These symbols are libtorrent::entry::dict() and the const version of it. * libtorrent-rasterbar.so.10 instead exports libtorrent::entry::dict[abi:cxx11](). * The most recent upload has "debian/rules: Pass --std=c++14" without any explanation (made with "export DEB_CXXFLAGS_MAINT_APPEND = -std=c++14"). * The build log shows that most compilation commands have both --std=c++11 and -std=c++14, 463 of them having -std=c++14 later and 80 having --std=c++11 later. All of the latter commands seem to be for Python bindings. * There is some magic parsing in bindings/python/setup.py related to extra flags, with -std= being explicitly mentioned in a comment. * There seem to be some ABI compatiblity hacks in the code itself, see TORRENT_CXX11_ABI (though it looks like it's only in CMakeLists.txt while the package uses autotools.), it's also says it's about "clients building with C++14 against libtorrent build with C++11" not vice versa. So it looks like the Python bindings are compiled incorrectly, but I don't see an obvious way to fix that, probably the setup.py magic needs fixing. -- WBR, wRAR
signature.asc
Description: PGP signature
