[BUG] mpcplus shared library error on Linux Mint

[JOJ0]

Hi, I took on a new project and installed mpplus on an older machine. This time it's debian-like, Linux Mint 21.1. Vera to be specific. It seems there is a similar shared library issue with mpcplus as I reported before on Arch/Manjaro.

Was installed before already, just so you have a log of which packages I downloaded an installed:

root@veery:~# apt install ./MusicPlayerPlus_3.0.1-1.amd64.deb ./mpcplus_1.0.0-1.amd64.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'musicplayerplus' instead of './MusicPlayerPlus_3.0.1-1.amd64.deb'
Note, selecting 'mpcplus' instead of './mpcplus_1.0.0-1.amd64.deb'
mpcplus is already the newest version (1.0.0-1).
musicplayerplus is already the newest version (3.0.1-1).
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

$ mppinit

MusicPlayerPlus initialization has previously been performed
and there is an existing MusicPlayerPlus configuration.

Preserve existing, Overwrite existing, Skip ? (p/o/s) o

Initializing MusicPlayerPlus, please wait ...Unsupported platform

    No mpplus-essentia release asset found for this platform ...
    No mpplus-bliss release asset found for this platform ...
    Installing configuration files in /home/jostl/.config ...
    Creating MusicPlayerPlus terminal profiles ...
    Installing MPD configuration in /home/jostl/.config/mpd ...
    Installing PipeWire configuration in /home/jostl/.config/pipewire ...
    Installing Beets configuration in /home/jostl/.config/beets ...
    Installing Calliope configuration in /home/jostl/.config/calliope ...
    Installing Kitty configuration in /home/jostl/.config/kitty ...
    Installing Mopidy configuration in /home/jostl/.config/mopidy ...
    Installing Navidrome configuration in /home/jostl/.config/navidrome ...
    Installing yt-dlp configuration in /home/jostl/.config/yt-dlp ...
    Setting up user system services in /home/jostl/.config/systemd/user ...
    Setting HOME in configuration files ...
    Setting up default tmux configuration ...
    Installing tmux plugins ...
    Installing custom Beets plugins ...
    Installing Python modules and Beets plugins ...
    Ensure YAMScrobbler module is current version ...
    Modules: install unidecode, upgrade six, upgrade PySocks, upgrade asciimatics, upgrade beautifulsoup4, upgrade beets, upgrade pylast, upgrade beets-describe, upgrade beets-yearfixer, upgrade beetcamp, upgrade beets-xtractor, upgrade python-mpd2, upgrade requests, upgrade sacad, upgrade tmuxp, upgrade setuptools, upgrade calliope-music, upgrade bandcamp-downloader, upgrade scdl, install flask-cors, upgrade iniparse, install ueberzug, done!

    Verifying minimum version of PyYAML module is installed ...
    Patching Beets plugins ...
    Syncing MusicPlayerPlus configuration across all configs ... done.

MusicPlayerPlus Initialization Complete

Music library location set to ~/Music in:
    /home/jostl/.config/mpprc
Modify /home/jostl/.config/mpprc 'MUSIC_DIR' to change this.
If 'MUSIC_DIR' is modified, run 'mppinit sync'

Download albums in your Bandcamp collections with:
    mppinit bandcamp
Download favorites in your Soundcloud account with:
    mppinit soundcloud
Import the music library into the Beets media management system:
    mppinit import
After the import has completed, perform an update of the Beets
library metadata, genres, and album cover art:
    mppinit metadata
Activate the Mopidy music server:
    mppinit mopidy
Activate the Navidrome streaming music server:
    mppinit navidrome
Activate the YAMS Last.fm scrobbler:
    mppinit yams

Visit the MusicPlayerPlus Wiki at:
    https://github.com/doctorfree/MusicPlayerPlus/wiki

Buy Doctorfree a cup of coffee at:
    https://github.com/sponsors/doctorfree

$ mpcplus
mpcplus: error while loading shared libraries: libboost_filesystem.so.1.71.0: cannot open shared object file: No such file or directory

[doctorfree]

This issue and the similar issue you encountered on other platforms is due to building in one environment and executing in another environment where the two environments do not have the same version of Boost libraries installed. Usually shared libraries have an embedded SONAME which includes a version string but only the major version number. The Boost libraries apparently build with an embedded SONAME that includes major and minor version strings. That's their decision and maybe it is necessary if the API is incompatible between minor version releases.

I could fool around with shared library SONAME when linking against Boost libraries but that runs the risk of hitting some incompatibility in the API between versions. I have decided to rebuild mpcplus using static Boost libraries.

[doctorfree]

I updated the mpcplus package to link with static Boost libraries. This should fix the shared library version issue. MusicPlayerPlus initialization with mppinit should pick up this latest release of mpcplus automatically.

First, remove any previously installed mpcplus package then install MusicPlayerPlus and initialize with mppinit. Or, re-run mppinit if MusicPlayerPlus is already installed. Unfortunately, mppinit does not yet detect if mpcplus needs to be updated so it is necessary to remove that package first.

[doctorfree]

Should be fixed in v3.0.1r2

https://github.com/doctorfree/MusicPlayerPlus/releases/tag/v3.0.1r2

[JOJ0]

Unfortunately there is another one as you were assuming here already: https://github.com/doctorfree/MusicPlayerPlus/issues/22#issuecomment-1387443467

$ mpcplus
mpcplus: error while loading shared libraries: libicui18n.so.66: cannot open shared object file: No such file or directory

[doctorfree]

I was hoping that wouldn't happen but kinda figured it would. There are a few ways to proceed. I can try building with a static libicui18n but this path could just reveal another shared library version issue, and another, and another. I could try building with all static libraries but that did not work the last time I tried so there would be some delay figuring that out. Or I could withdraw zst support on Arch and Arch-like platforms and force Arch users to use the PKGBUILD.

PKGBUILD (and other systems like brew on macOS) has the advantage of recompiling on the platform on which it is installing. That avoids this and many other issues. But for a large package with many binaries it can be time consuming.

I will try building with a static libicui18n first. Can you provide me with details of your operating system and distribution environment so I can replicate it here with a VM in Proxmox? Is this occurring on Arch or Manjaro or some other distribution? Thanks for helping with this.

[JOJ0]

Linux Mint current/latest as of now (Tried to stick with the issue title this time :-))

FIXME will provide all the details in a couple of hours...

[doctorfree]

Ah, Linux Mint is Debian based, right? So this occurred when installing with MusicPlayerPlus_3.0.1-3.deb correct?

If so then my idea of forcing a makepkg for Arch users would not help here. In this case it looks like I would need to provide distribution specific packages. Or a dependency on a specific version of shared libraries. Or figure out how to build a static binary that executes on all flavors.

No hurry on the details, I am not going to have much time to work on this until Monday or Tuesday.

[doctorfree]

@JOJ0 I managed to squeeze in some time this morning to relink mpcplus with additional static libraries. This was put together quickly and I will not have time to do thorough testing for a couple of days but it works on Ubuntu Linux and may as well on Mint.

To try it out, uninstall the mpcplus package, uninstall the MusicPlayerPlus package, and re-install MusicPlayerPlus.

[JOJ0]

Install the same version of MusicPlayerPlus package? (https://github.com/doctorfree/MusicPlayerPlus/releases/download/v3.0.1r3/MusicPlayerPlus_3.0.1-3.deb) Where will it pull from the mpcplus package on mppinit? I don't see a new release on github? Or does it pull from somewhere else? Just to make sure I understand correctly. Thanks!

[JOJ0]

Just tried whith the reinstalled MusicPlayerPlus package:

$ mppinit

Initializing MusicPlayerPlus, please wait ...Unsupported platform

        No mppcava release asset found for this platform ...
        No mpcplus release asset found for this platform ...
        No mpplus-essentia release asset found for this platform ...
        No mpplus-bliss release asset found for this platform ...
        Installing configuration files in /home/jostl/.config ...
...

Because on my last try I installed the mpcplus package manually - I downloaded it from the mpcplus github repo release.

[JOJ0]

Oh man, I see it now, how stupid is that? They write "ubuntu debian" for ID_LIKE... Pfff, ok will quickfix that. No worries and not our fault but funny distro packagers haha ;-)

$ cat /etc/os-release
NAME="Linux Mint"
VERSION="21.1 (Vera)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21.1"
VERSION_ID="21.1"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=vera
UBUNTU_CODENAME=jammy

[doctorfree]

I can grep for "debian" in the ID_LIKE setting. I have a question for you.

Some platforms like Arch, macOS, and BSD have packaging systems that enable native compilation as part of the installation process. This avoids issues like shared library SONAME version mismatch and ensures the resulting binaries are compiled and linked with native headers and libraries.

Arch and Arch-like platforms support this with makepkg and PKGBUILD. But I am not familiar enough with the Arch community yet to feel confident about forcing compilation during install of Arch packages. What does the Arch community expect/prefer?

Should I provide a precompiled *.zst package as well as the PKGBUILD ? Or just the PKGBUILD ?

MusicPlayerPlus is in the Arch User Repositoryy (AUR) and can be installed using PKGBUILD from there. My initial thought was to provide a binary package in the MusicPlayerPlus repository releases to augment that.

So, this is off topic. I just wanted to get your opinion.

[doctorfree]

Where will it pull from the mpcplus package on mppinit? I don't see a new release on github? Or does it pull from somewhere else?

In mppinit the appropriate package is installed from the mpcplus repository latest release. So I do not need to rev the MusicPlayerPlus package to rev mpcplus, I just need to update the mpcplus latest release. I cheated and did not create a new mpcplus release for this test Debian package install, I just replaced the existing Debian amd64 package in the latest release. If I'm happy with the tests I will roll a new mpcplus release but no need for a new MusicPlayerPlus release.

I'm thinking of adding an "update" argument to mppinit to specify an update to a previously installed mpcplus or mppcava package. The modular installation also allows me to rev the MusicPlayerPlus package rapidly and easily as it is now architecture independent.

[JOJ0]

Arch and Arch-like platforms support this with makepkg and PKGBUILD. But I am not familiar enough with the Arch community yet to feel confident about forcing compilation during install of Arch packages. What does the Arch community expect/prefer?

Should I provide a precompiled *.zst package as well as the PKGBUILD ? Or just the PKGBUILD ?

MusicPlayerPlus is in the Arch User Repositoryy (AUR) and can be installed using PKGBUILD from there. My initial thought was to provide a binary package in the MusicPlayerPlus repository releases to augment that.

So, this is off topic. I just wanted to get your opinion.

I'm not an Arch user for a very long time yet, about a year, and also only use the well, "baby-arch" Manjaro, haha ;-))

So not sure what the community expects but from what I see often when updating or installing stuff from AUR, there is quite a lot of PKGBUILD and compiing thing in general going on when I install/update, so yes I'd say, just providing a buildable package seems like a good idea and most of all: If it helps limiting the burden of packaging stuff for you, go for it! Definitely!

I only have sooome packaging experience with debian with one of my projects, which I have to admit gave up because debian packagint is quite some hassle and bringin into the official repos is even more of a hassle. I do quite some Python stuff and packaging-wise I think it's sufficient for most people these days to have a proper pip-installable package and a github release providing release notes. Not sure what others think but most of my pkages are for more or less skilled people anyway so why bother and package for the distro which get's outdated anyway in a jiff. Off topic as well but since we talking about opinions :-)

[doctorfree]

Thanks for sharing your views. Yes, Debian and RPM packaging are a pain. I was pleased to learn how easy Arch packaging is. I will mull over how to deal with PKGBUILD and zst releases.

One of the primary goals of several of my projects is to make hard things easy. For example, with MusicPlayerPlus I wanted to provide a relatively easy way to setup a self hosted music server, even doing a Spotify-like thing, without having to be an advanced user. So packaging is important in that regard. And those users probably aren't using Arch, they are using Ubuntu and Fedora. Well, they are probably using macOS and Windows but maybe someday they use Linux.

[JOJ0]

Where will it pull from the mpcplus package on mppinit? I don't see a new release on github? Or does it pull from somewhere else?

In mppinit the appropriate package is installed from the mpcplus repository latest release. So I do not need to rev the MusicPlayerPlus package to rev mpcplus, I just need to update the mpcplus latest release. I cheated and did not create a new mpcplus release for this test Debian package install, I just replaced the existing Debian amd64 package in the latest release. If I'm happy with the tests I will roll a new mpcplus release but no need for a new MusicPlayerPlus release.

I'm thinking of adding an "update" argument to mppinit to specify an update to a previously installed mpcplus or mppcava package. The modular installation also allows me to rev the MusicPlayerPlus package rapidly and easily as it is now architecture independent.

Thanks for the explanation.

I can confirm that mpcplus is now running fine with the new static libs build. :tada: Nice work! Thanks so much! <3

[doctorfree]

FYI, current releases of mpcplus and mppcava take the approach of building with static libraries where needed, providing appropriate dependencies where needed, and providing both PKGBUILD and *.zst binary distributions for Arch and Arch-like platforms. This may change in the future but moving to PKGBUILD only for these platforms would require significant changes to the mppinit process so I decided to delay that until we get additional testing and/or run into additional issues with shared libraries.