Created attachment 427844 [details] emerge --info Hello, I am compiling right now a new server with Gentoo and I am installing deluge. During compile phase I had this problem: >>> Emerging (1 of 1) net-p2p/deluge-1.3.12-r2::gentoo * deluge-1.3.12.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking deluge-1.3.12.tar.bz2 to /var/tmp/portage/net-p2p/deluge-1.3.12-r2/work >>> Source unpacked in /var/tmp/portage/net-p2p/deluge-1.3.12-r2/work >>> Preparing source in /var/tmp/portage/net-p2p/deluge-1.3.12-r2/work/deluge-1.3.12 ... * Applying deluge-1.3.5-disable_libtorrent_internal_copy.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/net-p2p/deluge-1.3.12-r2/work/deluge-1.3.12 ... >>> Source configured. >>> Compiling source in /var/tmp/portage/net-p2p/deluge-1.3.12-r2/work/deluge-1.3.12 ... /usr/bin/python2.7 setup.py build Traceback (most recent call last): File "setup.py", line 210, in <module> import deluge._libtorrent File "/var/tmp/portage/net-p2p/deluge-1.3.12-r2/work/deluge-1.3.12/deluge/_libtorrent.py", line 59, in <module> import libtorrent as lt ImportError: /usr/lib64/python2.7/site-packages/libtorrent.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
Created attachment 427846 [details] build.log
The bug seems related to net-libs/rb_libtorrent-1.0.9. If I use the stable one through package.mask, deluge compiles flawlessly.
(In reply to Gian Luca Dalla Torre from comment #2) > The bug seems related to net-libs/rb_libtorrent-1.0.9. > If I use the stable one through package.mask, deluge compiles flawlessly. Unfortunately 1.0.8 was just broken too by the incomplete removal of python 3.3 support, see: https://github.com/gentoo/gentoo/pull/1019
(In reply to Holger Hoffstätte from comment #3) > (In reply to Gian Luca Dalla Torre from comment #2) > > The bug seems related to net-libs/rb_libtorrent-1.0.9. > > If I use the stable one through package.mask, deluge compiles flawlessly. > > Unfortunately 1.0.8 was just broken too by the incomplete removal of > python 3.3 support, see: https://github.com/gentoo/gentoo/pull/1019 Your pull request has been merged and compiling deluge with rb_libtorrent-1.0.8 works correctly. Definitely the problem is in version 1.0.9 of lib torrent-rastebar.
Works for me... Have you tried rebuilding rb_libtorrent?
Just in case: give me the output of # emerge -1pqv =net-libs/rb_libtorrent-1.0.9 and # emerge -1pqv =net-p2p/deluge-1.3.12-r3 Thanks.
(In reply to Paolo Pedroni from comment #5) > Works for me... Have you tried rebuilding rb_libtorrent? Are you using boost >1.58? Because with 1.58 I got exactly the original message ("undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE") even after building libtorrent-1.0.9. libtorrent-1.0.9 has "fixes" for building with boost-1.60, so I suspect this broke the python bindings for older releases. Unfortunately the libtorrent git is a mess with no clear branch history, so I haven't yet been able to find the exact change that broke/fixed the python bindings.
(In reply to Holger Hoffstätte from comment #7) > (In reply to Paolo Pedroni from comment #5) > > Works for me... Have you tried rebuilding rb_libtorrent? > > Are you using boost >1.58? Because with 1.58 I got exactly the original > message ("undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE") > even after building libtorrent-1.0.9. libtorrent-1.0.9 has "fixes" for > building with boost-1.60, so I suspect this broke the python bindings for > older releases. > > Unfortunately the libtorrent git is a mess with no clear branch history, so > I haven't yet been able to find the exact change that broke/fixed the python > bindings. Nope, current stable: 1.56.0-r1.
(In reply to Paolo Pedroni from comment #8) > > Are you using boost >1.58? Because with 1.58 I got exactly the original > > Nope, current stable: 1.56.0-r1. OK then..with ~1.58.0-r1: holger>emerge -1pqv \=net-libs/rb_libtorrent-1.0.9 -1pqv \=net-p2p/deluge-1.3.12-r3 [ebuild U ] net-libs/rb_libtorrent-1.0.9 [1.0.8] USE="python ssl -debug -doc -examples -static-libs {-test}" PYTHON_TARGETS="python2_7 python3_5 -python3_4" [ebuild R ] net-p2p/deluge-1.3.12-r3 USE="geoip gtk libnotify setproctitle -sound -webinterface" PYTHON_TARGETS="python2_7" Remove -p, build, libtorrent completes, deluge starts, boom: .. /usr/bin/python2.7 setup.py build Traceback (most recent call last): File "setup.py", line 210, in <module> import deluge._libtorrent File "/tmp/portage/net-p2p/deluge-1.3.12-r3/work/deluge-1.3.12/deluge/_libtorrent.py", line 59, in <module> import libtorrent as lt ImportError: /usr/lib64/python2.7/site-packages/libtorrent.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE ..
(In reply to Holger Hoffstätte from comment #9) > holger>emerge -1pqv \=net-libs/rb_libtorrent-1.0.9 -1pqv > \=net-p2p/deluge-1.3.12-r3 > [ebuild U ] net-libs/rb_libtorrent-1.0.9 [1.0.8] USE="python ssl -debug > -doc -examples -static-libs {-test}" PYTHON_TARGETS="python2_7 python3_5 > -python3_4" Any chance you can try with python3_4?
(In reply to Paolo Pedroni from comment #10) > (In reply to Holger Hoffstätte from comment #9) > > holger>emerge -1pqv \=net-libs/rb_libtorrent-1.0.9 -1pqv > > \=net-p2p/deluge-1.3.12-r3 > > [ebuild U ] net-libs/rb_libtorrent-1.0.9 [1.0.8] USE="python ssl -debug > > -doc -examples -static-libs {-test}" PYTHON_TARGETS="python2_7 python3_5 > > -python3_4" > > Any chance you can try with python3_4? Not unless you can tell me what the reason might be. I tried really hard to get rid of py3.4 and since this fails in py27 setup I don't see how that could possibly help. Besides people had the same problem with boost-python (exact same missing symbol) in 2011.
(In reply to Holger Hoffstätte from comment #11) > > Any chance you can try with python3_4? I did something else instead and added -python_targets_python3_5 to rb_libtorrent since I only need it for deluge. Result: \o/ Now everything still works after building 1.0.9 - no need to rebuild deluge (tested by running), though that works as well. Looks to me something is broken wrt. the python 2.7/3.x separation?
(In reply to Holger Hoffstätte from comment #11) > (In reply to Paolo Pedroni from comment #10) > > Any chance you can try with python3_4? > > Not unless you can tell me what the reason might be. I tried really hard to > get rid of py3.4 and since this fails in py27 setup I don't see how that > could possibly help. Besides people had the same problem with boost-python > (exact same missing symbol) in 2011. You're right, sorry. Brain fart on my part.
(In reply to Holger Hoffstätte from comment #12) > (In reply to Holger Hoffstätte from comment #11) > > > Any chance you can try with python3_4? > > I did something else instead and added -python_targets_python3_5 to > rb_libtorrent since I only need it for deluge. Result: \o/ > > Now everything still works after building 1.0.9 - no need to rebuild deluge > (tested by running), though that works as well. > > Looks to me something is broken wrt. the python 2.7/3.x separation? No idea, but I think the bug is in rb_libtorrent, at this point.
Probably you should hard mask this version until the bug is fixed to avoid potentially broken systems.
(In reply to Gian Luca Dalla Torre from comment #15) > Probably you should hard mask this version until the bug is fixed to avoid > potentially broken systems. I don't see why. Nothing relevant has changed in the ebuild since current stable. It's rb_libtorrent which should be fixed, IMHO. There's nothing else I can do.
Anyway, I'm emerging boost-1.58 now, to see if I can reproduce. It's going to take a few hours, since there's also libreoffice to rebuild. I'll let you know the results later, or most likely tomorrow.
I haven't had time (or motivation..) to dig into it, but this may lead someone in the right direction: # ldd /usr/lib/python2.7/site-packages/libtorrent.so linux-vdso.so.1 (0x00007fff043f2000) libtorrent-rasterbar.so.8 => /usr/lib64/libtorrent-rasterbar.so.8 (0x00007fa1c2638000) libboost_system.so.1.58.0 => /usr/lib64/libboost_system.so.1.58.0 (0x00007fa1c2433000) libboost_python-3.4.so.1.58.0 => /usr/lib64/libboost_python-3.4.so.1.58.0 (0x00007fa1c21e6000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007fa1c1e12000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.so.6 (0x00007fa1c1a8f000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libgcc_s.so.1 (0x00007fa1c1878000) libc.so.6 => /lib64/libc.so.6 (0x00007fa1c14dc000) libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007fa1c1265000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007fa1c0e29000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa1c0c0d000) /lib64/ld-linux-x86-64.so.2 (0x0000561118bbe000) librt.so.1 => /lib64/librt.so.1 (0x00007fa1c0a04000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fa1c0800000) libpython3.4m.so.1.0 => /usr/lib64/libpython3.4m.so.1.0 (0x00007fa1c036b000) libutil.so.1 => /lib64/libutil.so.1 (0x00007fa1c0167000) libm.so.6 => /lib64/libm.so.6 (0x00007fa1bfe6a000) libz.so.1 => /lib64/libz.so.1 (0x00007fa1bfc53000)
(In reply to Alex Maclean from comment #18) > I haven't had time (or motivation..) to dig into it, but this may lead > someone in the right direction: > > # ldd /usr/lib/python2.7/site-packages/libtorrent.so > linux-vdso.so.1 (0x00007fff043f2000) > libtorrent-rasterbar.so.8 => /usr/lib64/libtorrent-rasterbar.so.8 > (0x00007fa1c2638000) > libboost_system.so.1.58.0 => /usr/lib64/libboost_system.so.1.58.0 > (0x00007fa1c2433000) > libboost_python-3.4.so.1.58.0 => > /usr/lib64/libboost_python-3.4.so.1.58.0 (0x00007fa1c21e6000) > libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 > (0x00007fa1c1e12000) > libstdc++.so.6 => > /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.so.6 (0x00007fa1c1a8f000) > libgcc_s.so.1 => > /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libgcc_s.so.1 (0x00007fa1c1878000) > libc.so.6 => /lib64/libc.so.6 (0x00007fa1c14dc000) > libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007fa1c1265000) > libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 > (0x00007fa1c0e29000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa1c0c0d000) > /lib64/ld-linux-x86-64.so.2 (0x0000561118bbe000) > librt.so.1 => /lib64/librt.so.1 (0x00007fa1c0a04000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007fa1c0800000) > libpython3.4m.so.1.0 => /usr/lib64/libpython3.4m.so.1.0 > (0x00007fa1c036b000) > libutil.so.1 => /lib64/libutil.so.1 (0x00007fa1c0167000) > libm.so.6 => /lib64/libm.so.6 (0x00007fa1bfe6a000) > libz.so.1 => /lib64/libz.so.1 (0x00007fa1bfc53000) Part of your libtorrent.so library is linked against python3.4; I wonder why? Mine, which works, conversely is: # ldd /usr/lib/python2.7/site-packages/libtorrent.so linux-vdso.so.1 (0x00007ffdb71c2000) libtorrent-rasterbar.so.8 => /usr/lib64/libtorrent-rasterbar.so.8 (0x00007fc6df2d4000) libboost_system.so.1.58.0 => /usr/lib64/libboost_system.so.1.58.0 (0x00007fc6df2cf000) libboost_python-2.7.so.1.58.0 => /usr/lib64/libboost_python-2.7.so.1.58.0 (0x00007fc6df27e000) libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007fc6df0b3000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.so.6 (0x00007fc6def22000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libgcc_s.so.1 (0x00007fc6def0b000) libc.so.6 => /lib64/libc.so.6 (0x00007fc6deb6c000) libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007fc6de8fd000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007fc6de4ab000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc6de28f000) /lib64/ld-linux-x86-64.so.2 (0x000055c9c3a71000) librt.so.1 => /lib64/librt.so.1 (0x00007fc6de086000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc6dde82000) libutil.so.1 => /lib64/libutil.so.1 (0x00007fc6ddc7f000) libm.so.6 => /lib64/libm.so.6 (0x00007fc6dd982000) libz.so.1 => /lib64/libz.so.1 (0x00007fc6dd96c000)
I cannot reproduce. I upgraded boost to 1.58.0-r1, installed python-3.5.1-r2, rebuild boost and rb_libtorrent with USE=python_targets_python3_5 and still deluge compiles fine and /usr/lib/python2.7/site-packages/libtorrent.so has only python-2.7 libraries in it. I have really no idea what to do next. Suggestions welcome...
I had the same issue with: - boost 1.58.0-r1 - rb_libtorrent 1.0.9 - deluge 1.3.12-r3 PYTHON_TARGETS in make.conf lists python2_7, python3_4 and python3_5. Reinstalling rb_libtorrent and deluge with USE="-python3_4" did not solve it. Reinstalling with USE="-python_targets_python3_4 -python_targets_python3_5" did, however. I also found two[1] links[2] that seem to be about the same kind of issue, maybe they could help with some ideas? [1]: http://stackoverflow.com/a/5814241/106471 [2]: https://github.com/belltailjp/selective_search_py/issues/2
As recommended by Torbjörn Lönnemark, Reinstalling rb_libtorrent with USE="-python_targets_python3_4 -python_targets_python3_5" solved it for me.
suggesting no longer supported py py2.7. What is going on here? deluge-1.3.12-r2 has been removed already. net-p2p/deluge/deluge-1.3.12-r3.ebuild has PYTHON_COMPAT=( python2_7 ) this is a mess * net-libs/rb_libtorrent Available versions: 0.16.17^t (~)0.16.17-r2^t (~)0.16.19^t (~)1.0.7^t (~)1.0.8^t (~)1.0.9^t {debug doc examples python ssl static-libs test PYTHON_TARGETS="python2_7 python3_3 python3_4 python3_5"} to begin with, net-libs/rb_libtorrent requires [${PYTHON_USEDEP}] since it supports various python implentations. net-libs/rb_libtorrent/rb_libtorrent-1.0.9.ebuild has PYTHON_COMPAT=( python2_7 python3_{4,5} ) Having it work with rb_libtorrent with USE="-python_targets_python3_4 -python_targets_python3_5" is more a case of two or more wrongs making a right.
(In reply to Ian Delaney from comment #23) > suggesting no longer supported py py2.7. > > What is going on here? deluge-1.3.12-r2 has been removed already. > > net-p2p/deluge/deluge-1.3.12-r3.ebuild > has PYTHON_COMPAT=( python2_7 ) Same thing happens with -r3, anyway. I changed the description to reflect this. As I said in comment #16, nothing relevant has changed between -r2 and -r3. > > this is a mess > > * net-libs/rb_libtorrent > Available versions: 0.16.17^t (~)0.16.17-r2^t (~)0.16.19^t (~)1.0.7^t > (~)1.0.8^t (~)1.0.9^t {debug doc examples python ssl static-libs test > PYTHON_TARGETS="python2_7 python3_3 python3_4 python3_5"} > > to begin with, net-libs/rb_libtorrent requires [${PYTHON_USEDEP}] since it > supports various python implentations. So this implies that the problem is in rb_libtorrent, as I suggested before, doesn't it?
I've partially fixed this bug about a week ago in my overlay, but somehow forgot to merge it into the gentoo-tree. Anyway, the bug is definitely somewhere in libtorrent-rasterbar, as already pointed out multiple times here. The issue is that what boost-python bindings is the library linked against depends on the python version which the configuration (or build?) was run with. This means that libtorrent-rasterbar can currently use only a single python implementation and which one is it depends on `python_setup` and not on `--with-boost-python=*`. So my quick fix was: ``` src_configure() { use python && python_setup $(usex python_targets_python2_7 'python2*' 'python3*') ``` Also I suggest to change the title of this bug to something like: `net-libs/rb_libtorrent-1.0.9[python]: python bindings are linked against wrong libboost_python version`
*** Bug 577992 has been marked as a duplicate of this bug. ***
Created attachment 428976 [details, diff] rindeal-overlay.diff Today I gave this bug another thought and realized that python-r1 eclass has such nice functions as `python_foreach_impl()` and `python_copy_sources()`. With these the issue has been solved quickly. You can have a look at it in my overlay https://github.com/rindeal/gentoo-overlay/blob/master/net-libs/libtorrent-rasterbar/libtorrent-rasterbar-1.0.9-r1.ebuild.
(In reply to Jan Chren (rindeal) from comment #27) > Created attachment 428976 [details, diff] [details, diff] > rindeal-overlay.diff > > Today I gave this bug another thought and realized that python-r1 eclass has > such nice functions as `python_foreach_impl()` and `python_copy_sources()`. > With these the issue has been solved quickly. > > You can have a look at it in my overlay > https://github.com/rindeal/gentoo-overlay/blob/master/net-libs/libtorrent- > rasterbar/libtorrent-rasterbar-1.0.9-r1.ebuild. Has this been pushed to the gentoo tree? In case not, do you mind if I do?
(In reply to Paolo Pedroni from comment #28) > (In reply to Jan Chren (rindeal) from comment #27) > > Created attachment 428976 [details, diff] [details, diff] [details, diff] > > rindeal-overlay.diff > > > > Today I gave this bug another thought and realized that python-r1 eclass has > > such nice functions as `python_foreach_impl()` and `python_copy_sources()`. > > With these the issue has been solved quickly. > > > > You can have a look at it in my overlay > > https://github.com/rindeal/gentoo-overlay/blob/master/net-libs/libtorrent- > > rasterbar/libtorrent-rasterbar-1.0.9-r1.ebuild. > > Has this been pushed to the gentoo tree? In case not, do you mind if I do? I assume that no words means Yes ;)
(In reply to Paolo Pedroni from comment #28) > Has this been pushed to the gentoo tree? In case not, do you mind if I do? I'm not sure what you're asking about and who. All changes to ebuilds are in the publicly viewable git repo. (In reply to Gian Luca Dalla Torre from comment #29) > I assume that no words means Yes ;) I guess you meant: "No, he doesn't mind." At least in my part of the world silence mean agreement.
(In reply to Jan Chren (rindeal) from comment #30) > (In reply to Paolo Pedroni from comment #28) > > Has this been pushed to the gentoo tree? In case not, do you mind if I do? > I'm not sure what you're asking about and who. All changes to ebuilds are in > the publicly viewable git repo. > > (In reply to Gian Luca Dalla Torre from comment #29) > > I assume that no words means Yes ;) > I guess you meant: "No, he doesn't mind." At least in my part of the world > silence mean agreement. In my part too ;) Sorry for misunderstanding... Will it be pushed to the portage?
I can confirm this behavior and will try to look at the proposed ebuild soon.
Nope on this, yet?
I sent a patch for the ebuild on github. I think it's under review. It's the most I can do.
commit 22bbdc98ce5ca1540fea497ea82e1fecc6d1e4b5 (HEAD -> master) Author: PPed72 <paolo.pedroni@iol.it> AuthorDate: Fri Apr 15 15:35:19 2016 +0200 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: Thu Apr 21 19:45:59 2016 +0000 net-libs/rb_libtorrent: fix linking of python bindings Thanks to Jan Chren (rindeal) <dev.rindeal+bugs.gentoo.org@gmail.com> for the ebuild, I've simply ported the good bits to the current one. Gentoo-Bug: https://bugs.gentoo.org/576910 Closes: https://github.com/gentoo/gentoo/pull/1262 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> net-libs/rb_libtorrent/metadata.xml | 4 ++++ net-libs/rb_libtorrent/rb_libtorrent-1.0.9-r1.ebuild | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 103 insertions(+) create mode 100644 net-libs/rb_libtorrent/rb_libtorrent-1.0.9-r1.ebuild Thanks for the PR!
