Jeremie Courreges-Anglas writes: > On Thu, Aug 06 2020, Nam Nguyen <n...@berkeley.edu> wrote: > Done, I have committed your diff + a few other tweaks yesterday. I have > pointed this bug and your diff to the folks who handled the LLVM update > in base. There have been discussions about moving to llvm-10.0.1. >
Thank you. >> I propose waiting until rsadowski@'s devel/boost 1.67 before unbreaking >> libtorrent-rasterbar. I can look into updating libtorrent-rasterbar to >> 1.2.8 until then. There is discussion regarding a mechanism for boost >> python numbering. > > Is libtorrent-rasterbar currently broken for other reasons? On a minor note ConvertUTF.cpp has a license issue that caused Debian to remove libtorrent-rasterbar. Upstream is removing this file and backporting it to an upcoming 1.2.9 release. See: https://github.com/arvidn/libtorrent/issues/4951 More critically, I just noticed that the libtorrent-rasterbar that I posted didn't fully use rsadowski@'s devel/boost patch. I erroneously used: --with-boost-python=boost_python3 \ instead of rsadowski@'s: --with-boost-python=boost_python${MODPY_VERSION:C/\.//g} \ This meant that I linked against libboost_python3.so.10.0 instead of libboost_python38.so.11.0. This is a good test to see if deluge is using libtorrent correctly. $ python3 -c "from deluge._libtorrent import lt; print(lt.version)" Alternatively, check the `make update-plist' of deluge: broken: Warning: libtorrent (libtorrent-rasterbar) not found: Cannot load specified object ===> Faking installation for deluge-2.0.3p1 good: Info: Found libtorrent (1.2.3.0) installed. ===> Faking installation for deluge-2.0.3p1 It seems like I am running into the same problem I encountered while trying to move to python 3 bindings a while ago. I will keep poking at this with the goal of getting libtorrent-rasterbar to link against the 1.67 boost python bindings. In summary: - libtorrent-rasterbar 1.2.8 linked against proposed devel/boost 1.67 is broken. deluge starts in thin client mode. - libtorrent-rasterbar 1.2.3 linked against old devel/boost 1.66 (libboost_python3.so.10.0) with devel/llvm 10.0.1 patch works. > If > possible, I'd prefer if we could update/fix base-clang instead of moving > libtorrent-rasterbar to ports-clang. Yes, this sounds good. from old e-mail: Nam Nguyen writes: > boost 1.67 changes the python naming convention to be of the form > libboost_python{27,37}.so.9.0. boost 1.67 also tries to allow building > against multiple versions of python in one run of b2. While my initial > approach was to try to backport 1.67 fixes alluded to in the changelog, > I quickly abandoned this effort because I was not getting > libtorrent-rasterbar to link properly. `make port-lib-depends-check' > inside libtorrent-rasterbar would report that boost_python3 was > unused. I suggest revisiting this during the next boost update. > > https://www.boost.org/users/history/version_1_67_0.html > https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71 > > Python: > > The library name now includes the version suffix of the Python > version used to compile it. For example, a variant compiled with > Python 2.7 will produce library names boost_python27 and > boost_numpy27, etc.. Combined with a related fix in Boost.Build, > this means that it is now possible to build variants for multiple > Python versions in a single build process. >