qbittorrent doesn't launch anymore after libtorrent-rasterbar10 update

[valynor]

Latest qbittorent 4.2.1 on Linux Mint 19.3 doesn't start anymore after libtorrent-rasterbar10 update from 1.2.3 to 1.2.5 (standard update that just came in):

~$ qbittorrent qbittorrent: symbol lookup error: qbittorrent: undefined symbol: _ZN10libtorrent9peer_info11interestingE

~$ apt list libtorrent-rasterbar10 Listing... Done libtorrent-rasterbar10/bionic,now 1.2.5+git20200323.0d06d47a29-1ppa1~18.04 amd64 [installed]

~$ apt list qbittorrent Listing... Done qbittorrent/bionic,now 1:4.2.0.99~202003190933-6820-2bf340a~ubuntu18.04.1 amd64 [installed]

[sakurachan00]

same "symbol lookup error: qbittorrent: undefined symbol: _ZN10libtorrent9peer_info11interestingE"
ubuntu 18.04 using PPA

[rockhazard]

Same problem here. Linux Mint 19.3 on Ubuntu 18.04 PPA.

[sledgehammer999]

Yeah, I disabled deprecated functions on libtorrent package beginning with the above release. It probably broke the ABI for applications build with the deprecated functions on. The above release was a precursor for the v4.2.2 qbittorrent release. I had hoped that I would release it until now, but I had some trouble behind the scenes. Now I am out of time for today (need sleep).
You have 2 options:

1. If you can revert to the previous version of the libtorrent package
2. Wait about half-a-day to one day when I make the new v4.2.2 which will be able to use the new libtorrent package.

[valynor]

Will gladly wait the day, thx for the quick reply :)

[dausruddin]

Anyone who need to downgrade, you can remove current libtorrent-rasterbar10 then install the old version

This is for Ubuntu 18.04 64Bit

1. sudo dpkg -r --force-depends libtorrent-rasterbar10
2. Download old version of libtorrent-rasterbar10 libtorrent-rasterbar10_1.2.3+git20191216.68196dceae-1ppa1~18.04_amd64.deb
3. Install it, sudo dpkg -i libtorrent-rasterbar10_1.2.3+git20191216.68196dceae-1ppa1~18.04_amd64.deb

qbittorrent-nox (In my case) should be working fine. Just upgrade as usual when the new builds are up.

[Leopard1907]

Same issue here. Linux Mint 19.3 ( Ubuntu 18.04 based)

qbittorrent: symbol lookup error: qbittorrent: undefined symbol: _ZN10libtorrent9peer_info11interestingE

Thanks for the upcoming fix.

[Korios]

I have the same problem as well on Ubuntu 18.04 (qbittorrent: symbol lookup error: qbittorrent: undefined symbol: _ZN10libtorrent9peer_info11interestingE).
Both the stable qbittorrent version (4.2.0.99.xxx) and the version of the unstable Launchpad PPA (4.3.0.xxx) have the exact same problem.
I am trying the temporary fix suggested by dausruddin above, by downgrading libtorrent-rasterbar10 to version 1.2.3

[pelorios]

Same problem (Ubuntu 18.04.4) opened ticket before looking up for it (sorry newb here) closed it.
Tried duasruddin's temp fix, it worked thx man.
No worries sledgehammer, take your time man and thank you!

[sledgehammer999]

I just pushed a new libtorrent version on the PPAs. You should wait for them to build. They now have the deprecated functions enabled again. The new package version is 1.2.5+git20200323.0d06d47a29-2ppa1 (notice the -2ppa1 part).

And in a couple of hours I'll release qbittorrent v4.2.2 too.

[brunoais]

@sledgehammer999 For some reason, something is not going right on my end:

sudo add-apt-repository ppa:qbittorrent-team/qbittorrent-stable
sudo apt update

All fine until here. Then:

# sudo apt install libtorrent-rasterbar
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libtorrent-rasterbar

However:

# sudo apt install qbittorrent
qbittorrent is already the newest version (1:4.2.0.99~202003190933-6820-2bf340a~ubuntu18.04.1).

What am I missing here?

---

NVM. It should have been:

sudo apt install libtorrent-rasterbar10

[aldevel]

Hm, I'm not sure if I report this in the right place especially after it's closed but currently the same thing is happening on openSUSE Tumbleweed, no separated installation or such, simple from the official package, v4.2.5

qbittorrent: symbol lookup error: qbittorrent: undefined symbol: _ZN10libtorrent5entryC1ESt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES0_NS_3aux12strview_lessESaISt4pairIKS7_S0_EEE

[FranciscoPombal]

@aldevel
This is due to a recent problem in libtorrent. If the program that links against it uses >= C++ 14, which is the case for qbittorrent, you must either

• Build libtorrent with C++14 instead, and link against it built that way
• Build libtorrent with C++11, but pass -DCMAKE_CXX_STANDARD=11 in the command line when building it with CMake. This forces the TORRENT_CXX11_ABI compiler definition to be propagated to depending targets, which solves the problem.
• Build libtorrent with C++11, but when building qBittorrent, manually make sure the to files are compiled with the TORRENT_CXX11_ABI compiler definition.

Due to current limitations of qBittorrent's build system, the first alternative is the easiest, followed by the second and third.

[aldevel]

Thanks for the prompt response. So is this an ongoing issue with libtorrent for months now and that's the only workaround? Otherwise what do you mean building it with C++ 14? Is it not a given stuff already on your system? I mean if you build it with cmake then it will be installed regarding to given C++ related packages on your system isn't it? Anyway I'd rather install an other client. Definitely would give it shot if there would be a reasonable workaround.

[FranciscoPombal]

@aldevel

Thanks for the prompt response. So is this an ongoing issue with libtorrent for months now and that's the only workaround?

If you want to learn more about the issue itself, take a look at arvidn/libtorrent#4965 and the discussions that stemmed from it. The problem is essentially summarized here: arvidn/libtorrent#4965 (comment) - an internal container type that depends on the C++ standard used to build libtorrent leaks into its API, potentially leading to linking failures if the code linking against it uses a different C++ standard.

My original comment proposed not one, but three different workarounds. The first one is the easiest, IMO. The other two leverage the TORRENT_CXX11_ABI define that was introduced as an escape hatch to still be able to use libtorrent built with C++11 and not run into problems.

Otherwise what do you mean building it with C++ 14?

I mean such that the compiler uses -std=c++14 or higher when compiling the files. This is accomplished by simply building libtorrent with CMake by passing -DCMAKE_CXX_STANDARD=14 at configure time. Actually, if using libtorrent >= 8e46bdf81f9b5ec7bccd8ca400381773c284be61 (for example, 1.2.9) and a compiler that defaults to C++14 or higher (GCC >= 5, for example), you don't even need to pass that. Clang does default to C++98, so if you don't force C++14 when building libtorrent, Clang will build it with C++11, because that is the minimum requirement.

This seems to me like a packaging fail on OpenSUSE's part. Please submit a bug on their issue tracker asking them to fix it.
They have the following choices when building the package:

• If packaging libtorrent built with C++14 is acceptable, this should be preferred. You can force it with -DCMAKE_CXX_STANDARD=14, or, if using libtorrent >= 8e46bdf81f9b5ec7bccd8ca400381773c284be61 (for example, 1.2.9) and a compiler that defaults to C++14 or higher (GCC >= 5, for example), this is simply the default.
• If they wish to still be able to build libtorrent with C++11, make sure to build it with the TORRENT_CXX11_ABI definition and that that define gets propagated as a usage requirement to targets that link against libtorrent. If using CMake, this can be accomplished by passing -DCMAKE_CXX_STANDARD=11. See also https://github.com/arvidn/libtorrent/pull/5010/files about why this is.

[FranciscoPombal]

Original issue had been solved already. Recent problems in OpenSUSE now tracked at: #13322