Help Wizard

Step 1



Please see below the most popular frequently asked questions.

Loading article...

Loading faqs...


Ongoing Issues

Please see below the current ongoing issues which are under investigation.

Loading issue...

Loading ongoing issues...







the upcoming LTS Release of Ubuntu (Bionic) uses libcurl4, and that conflicts with libcurl3.

But the Spotify Desktop client depends on libcurl3...


Would it be possible to rebuild (a version of) spotify against libcurl4 for the Debian/Ubuntu repository?


Background-info why they upgraded/renamed to libcurl4 see :

  * Rename libcurl3 to libcurl4, because libcurl exposes an SSL_CTX via
    CURLOPT_SSL_CTX_FUNCTION, and this object changes incompatibly between
    openssl 1.0 and openssl 1.1.
  * debian/patches/03_keep_symbols_compat.patch: drop, since we are no longer
    claiming compatibility.



Accepted Solutions
Marked as solution

I uploaded a workaround to the testing debian repository.


If you follow the installation instructions at you just need to replace the word stable with testing. Instead of:

deb stable non-free

it should say:

deb testing non-free


View solution in original post

14 Replies

I'd also like to request a rebuild against libcurl4.  I doubt they'll work around this in Ubuntu, as it doesn't affect any of the 1st party packages. 


Even on my system, with 5 different desktops, all their default apps, and a lot of 3rd party packages, only the spotify-client package conflicts with the libcurl update.  So, fixing spotify and the few other packages that might need it is probably not much more work and avoids backpeddling on security issues.

This feels like it might be as painful as the libssl problems we have had. In fact, they are related. The recommended workaround right now would be to remove the debian package and install the snap instead.

sudo apt remove spotify-client
snap install spotify



Nobody is working actively on the build, test and release infrastructure for the linux desktop client. Setting that up for one additional released artifact per commit will be problematic.


Building against libcurl4 _instead_ of libcurl3 would be easier, but then suddenly all users who can't easily install libcurl4 won't be able to install the client.


I managed to change our old libssl dependency to dynamically load the version of libssl you have installed. I can't do that here, since the code that uses curl is shared by other non-desktop clients. It is possible, but not trivial.


One way out could be to build against libcurl3-gnutls or libcurl3-nss. I will try that, because it should be fairly easy to test.




Thanks for your response jooon.


I use for now the snap-build as workaround.


The incompabitlity between libcurl3 and libcurl4 for users is indeed a tricky problem.

Maybe that a static-link can offer a solution? Or as last resort distributing two different versions of the client?

Any progress on building against those other flavors of libcurl3? I'm using the snap as per your suggestion for the time being but it just doesn't offer the same responsiveness as the .deb package.


I did test the candidate version of the snap to see if it performed more like the deb package, but sadly it crashed everytime I tried to open it. The error messages are below in case it helps the dev team at all:




ATTENTION: default value of option force_s3tc_enable overridden by environment.

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

[] Couldn't make context current with X drawable.

[] gl::GLContext::MakeCurrent() failed

[] Widevine registration is not supported after context initialization

[] Failed to launch GPU process.



I'm running Kubuntu 18.04 LTS Beta 1 on a Lenovo ThinkPad T420s

An intellectual is someone whose mind watches itself. -Albert Camus
Marked as solution

I uploaded a workaround to the testing debian repository.


If you follow the installation instructions at you just need to replace the word stable with testing. Instead of:

deb stable non-free

it should say:

deb testing non-free


I'm not sure if you want bug reports here or in the debian stretch thread, but I've experienced failure as well with the new build.  We (gentoo) do not package as well.


I've tested building curl against gnutls and get the same failure.  I did have to patch the spotify ELF to point to the libcurl shared object though.


patchelf --replace-needed usr/bin/spotify


and the error...


/opt/spotify/spotify-client/spotify: /usr/lib64/ no version information available (required by /opt/spotify/spotify-client/spotify)
/opt/spotify/spotify-client/spotify: /usr/lib64/ no version information available (required by /opt/spotify/spotify-client/spotify)
/proc/self/exe: /usr/lib64/ no version information available (required by /proc/self/exe)
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
what(): set_option: Cannot assign requested address
Aborted (core dumped)


It seems like the 'most correct' solution may be to do the ifdef madness I think you aluded to earlier in the thread.  Then after some deprication time frame switch over to the new libcurl (probably whenever the mobile apps can link against it?).

The snap is broken this morning for me on 18.04LTS, so I'm back to the web client because of the libcurl compatibility issue with the spotify-client install. 


spotify_spotify.desktop[8172]: failed to create prefix path: /tmp/snap.rootfs_C2D74Z/var/lib/snapd/lib/vulkan/icd.d: Permission denied

I switched over to the testing deb repository:

~ > cat /etc/apt/sources.list.d/spotify.list
deb testing non-free

And I can now install spotify-client, and run it without problems on Ubuntu 18.04.

~ > dpkg -l | grep spotify
ii spotify-client 1: amd64 Spotify streaming music client

Thank you sir, that fixed it. Spotify should update their Linux install instructions to include the testing repo as an option:


sudo apt-key adv --keyserver hkp:// --recv-keys 0DF731E45CE24F27EEEB1450EFDC8610341D9410
# Stable Repo
echo deb stable non-free | sudo tee /etc/apt/sources.list.d/spotify.list
# Testing Repo
echo deb testing non-free | sudo tee /etc/apt/sources.list.d/spotify.list
sudo apt update;sudo apt install spotify-client

Has anyone tried to take the libcurl library from an older version of Ubuntu and put it on the path? Maybe its more trouble than its worth, but you could:

  1. Set up a VM with Ubuntu 17.10
  2. Install Spotify
  3. Find the binary (/usr/share/spotify/spotify)
  4. Run ldd, which shows the libraries needed.
  5. Copy the needed library to your host system, likely placing it in /usr/lib/x86_64-linux-gnu/.
  6. Run: sudo ldconfig

This is a hack, but it puts the needed library on the newer distro version, and doesn't conflict with the prior versions, since the libary versions are in the filename. So it shouldn't interfere with your other programs. Just a thought. The only problem is the rabbit hole of depencies, if the library you move over then has it's own dependencies.

Technology indistinguishable from magic is insufficiently advanced.

It's now in stable repo.

I see the new spotify-client for amd64 arch in the testing directory but there is no corresponding libcurl4 spotify-client for i386.


Is it possible to build the i386 version as well?

I have change the repository with the "testing" one. However, I'm still promt by the terminal that libcurl4 will be replace by libcurl3.

Suggested posts