LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Spotify client SlackBuild libcurl-gnutls.so.4 error, Slackware64 full install. (https://www.linuxquestions.org/questions/slackware-14/spotify-client-slackbuild-libcurl-gnutls-so-4-error-slackware64-full-install-4175628064/)

globetrotterdk 04-20-2018 08:48 AM

Spotify client SlackBuild libcurl-gnutls.so.4 error, Slackware64 full install.
 
I have been trying to sort this out off and on for about a week, without a solution, so I am throwing the problem out to the forum. The Spotify SlackBuild no longer works, as the Spotify client version is no longer available, so I downloaded spotify-client_1.0.77.338.g758ebd78-41_amd64.deb and modified the SlackBuild script to match. The install worked fine without any errors, but Spotify refuses to start, instead kicking up the following error message:
Code:

$ spotify
/opt/spotify/usr/bin/spotify: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory

Anyone have an idea what is going on? I know that I have the curl-7.59.0-x86_64-1_slack1 package installed and can find the files:
  • libcurl.so
  • libcurl.so.4
  • libcurl.so.4.4.0
  • libcurl.so.4.5.0
but no file that contains libcurl-gnutls.

Darth Vader 04-20-2018 09:47 AM

Long story short, that proprietary spotify-client_1.0.77.338.g758ebd78-41_amd64.deb is a Debian package (and build) which is not compatible with your Slackware OS.

jimX86 04-20-2018 01:10 PM

For a quick fix, maybe try this...
Code:

ln -s /usr/lib64/libcurl.so.4.5.0 /usr/lib64/libcurl-gnutls.so.4

volkerdi 04-20-2018 01:15 PM

Quote:

Originally Posted by jimX86 (Post 5845665)
For a quick fix, maybe try this...
Code:

ln -s /usr/lib64/libcurl.so.4.5.0 /usr/lib64/libcurl-gnutls.so.4

I somehow doubt that would work.

A bit of background information on this, old document, but still sums up the state of affairs: https://curl.haxx.se/legal/distro-dilemma.html

Basically, Debian (and Debian-based distros) distribute a version of curl that's linked with GnuTLS rather than OpenSSL. Nobody else does, as far as I'm aware.

I'd see if there's a version of the Spotify client intended for Fedora or some other non-Debian derived distro.

ponce 04-20-2018 02:12 PM

Quote:

Originally Posted by globetrotterdk (Post 5845583)
The Spotify SlackBuild no longer works, as the Spotify client version is no longer available

I hope I have understood this, but the deb version for which the SlackBuild has been tested is actually still available in the sbosrcarch mirror

http://slackware.uk/sbosrcarch/by-na...media/spotify/

jimX86 04-20-2018 04:19 PM

Quote:

Originally Posted by volkerdi (Post 5845666)
I somehow doubt that would work.

Well, it's an incredibly ugly kludge... but the program runs and I can play music.

I see no reason to upgrade though. I think that using the archived version is the better option.

globetrotterdk 04-20-2018 04:26 PM

Quote:

Originally Posted by volkerdi (Post 5845666)
I somehow doubt that would work.

Actually, it did :)

Quote:

Originally Posted by volkerdi (Post 5845666)
A bit of background information on this, old document, but still sums up the state of affairs: https://curl.haxx.se/legal/distro-dilemma.html

Interesting read.

Quote:

Originally Posted by volkerdi (Post 5845666)
Basically, Debian (and Debian-based distros) distribute a version of curl that's linked with GnuTLS rather than OpenSSL. Nobody else does, as far as I'm aware.

I'd see if there's a version of the Spotify client intended for Fedora or some other non-Debian derived distro.

That would require a serious rewrite of the SlackBuild script wouldn't it, or would ar still do the heavy lifting?

Ponce is correct, that the old version still can be found here.

globetrotterdk 04-20-2018 04:28 PM

Quote:

Originally Posted by jimX86 (Post 5845705)
Well, it's an incredibly ugly kludge... but the program runs and I can play music.

I see no reason to upgrade though. I think that using the archived version is the better option.

Probably, but as we both discovered, it does work, and I had already installed the newer version of Spotify...

Thanks to all for your replies. Very usefull and informative.

orbea 04-20-2018 06:19 PM

Whether it "works" or not, its an incredibly terrible hack that is liable to break something somewhere down the line. Probably when you no longer remember doing it...

jimX86 04-20-2018 10:56 PM

Which brings us back to using the older version. As far as I can tell, that's what the Fedora repos are doing. (If that's the best path, then the link on Slackbuilds.org would need to point to an archived copy, because Spotify doesn't seem to archive the older versions.)

FWIW, Spotify didn't update the i386 version.

lonestar_italy 04-21-2018 11:32 AM

If I may suggest, it's possible to use the flatpak package of Spotify client.

Flatpak itself is available in SlackBuilds repository, and after installing that it's possible to install Spotify client from Flathub and keep it updated without depending on Debian/Fedora package.

globetrotterdk 04-23-2018 04:48 AM

Quote:

Originally Posted by lonestar_italy (Post 5845934)
If I may suggest, it's possible to use the flatpak package of Spotify client.

Flatpak itself is available in SlackBuilds repository, and after installing that it's possible to install Spotify client from Flathub and keep it updated without depending on Debian/Fedora package.

Personally, I prefer AppImage to Flatpak, as an AppImage is largely self-contained, using the existing system libs, rather than have two copies (system and Flatpak) of QT, GTK, etc. libs, but it is good to know that Flatpak is available, should I need it. BTW, I took the general advice given in this thread, and deleted the symlink, uninstalled the upgraded version of Spotify and downloaded and installed the older version, so that I have a clean system.

55020 04-23-2018 06:18 AM

Quote:

Originally Posted by globetrotterdk (Post 5846484)
an AppImage is largely self-contained, using the existing system libs

The first part ("an AppImage is largely self-contained") is not true, because of the second part ("using the existing system libs").

And when AppImage doesn't work, this is the exact reason why it doesn't work: the person creating the AppImage has no idea which "existing system libs" actually exist.

jimX86 04-23-2018 10:30 AM

FWIW, I regret my initial post. I could try and explain my reasoning in this particular case, but the fact remains that my hack encourages bad practices. I can't really justify that.

The latest version is a proprietary binary that depends on libcurl-gnutls. AFAIK, there's no elegant solution to that.

My bigger concern at this point is whether I'm even willing to accept the security risks of the desktop client. Serious question... wouldn't the browser interface be more secure than keeping a port open all day?

lonestar_italy 04-23-2018 10:54 AM

Quote:

Originally Posted by globetrotterdk (Post 5846484)
Personally, I prefer AppImage to Flatpak, as an AppImage is largely self-contained,

I can agree with this, but the problem is that Spotify is not available as AppImage while it's available as Flatpak :)


All times are GMT -5. The time now is 08:43 PM.