This command was used: i686-pc-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro -pthread -L/usr/lib -O2 -march=athlon -mtune=athlon -pipe build/temp.linux-i686-2.6/src/peer_plugin.o build/temp.linux-i686-2.6/src/session_settings.o build/temp.linux-i686-2.6/src/create_torrent.o build/temp.linux-i686-2.6/src/filesystem.o build/temp.linux-i686-2.6/src/alert.o build/temp.linux-i686-2.6/src/utility.o build/temp.linux-i686-2.6/src/extensions.o build/temp.linux-i686-2.6/src/torrent_status.o build/temp.linux-i686-2.6/src/converters.o build/temp.linux-i686-2.6/src/torrent_handle.o build/temp.linux-i686-2.6/src/big_number.o build/temp.linux-i686-2.6/src/magnet_uri.o build/temp.linux-i686-2.6/src/peer_info.o build/temp.linux-i686-2.6/src/ip_filter.o build/temp.linux-i686-2.6/src/fingerprint.o build/temp.linux-i686-2.6/src/entry.o build/temp.linux-i686-2.6/src/version.o build/temp.linux-i686-2.6/src/module.o build/temp.linux-i686-2.6/src/torrent.o build/temp.linux-i686-2.6/src/session.o build/temp.linux-i686-2.6/src/torrent_info.o build/temp.linux-i686-2.6/src/datetime.o -L../../src/.libs -L/usr/lib -L/usr/lib -ltorrent-rasterbar -lboost_python-mt -lz -lboost_filesystem-mt -lboost_thread-mt -lssl -lcrypto -lboost_system-mt -lpython2.6 -o build/lib.linux-i686-2.6/libtorrent.so -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro -pthread -L/usr/lib While extra '-pthread' instances are just annoying, first '-L/usr/lib' causes the bindings to link with system lib, instead of the built one. On upgrade from net-libs/rb_libtorrent-0.14.4-r1, this results in linking to the old libtorrent-rasterbar.so.4, not built libtorrent-rasterbar.so.5. Linking command is generated by python' distutils.
So, kill the extra -L flag from compile or make the ebuild || die if old rb_libtorrent isn't unemerged first (little like what vlc is doing). Just great...
You've missed a part. I said "Linking command is generated by python' distutils.". I know very little about python, so I can't really tell why that extra part is added. Mind, that the other instance is OK, it's just a matter of order. Perhaps one of python people can give us a hint ?
So, OK, I'm lazy. That extra part comes from 'LDFLAGS="$LDFLAGS $BOOST_LDFLAGS"' line in configure.in. Most probably removing that line would fix the problem, as on Linux (don't know about FreeBSD), BOOST_LDFLAGS is just '-L/usr/lib' (at least here), but that would mean either eautoconf or patching existing configure.
Fixed without revbump.
