Citra: Prebuild binary: libsndio.so.6.1 cannot open shared object file

[JayFoxRox]

I tried running one of the latest Citra Canary prebuild Linux binaries (citra-linux-20180621-3153e29.tar.xz) on my Arch Linux:

./citra-qt: error while loading shared libraries: libsndio.so.6.1: cannot open shared object file: No such file or directory

even after installing the sndio package using the Arch Linux repos (which provides libsndio.so.7.0).
Note the absence of sndio from many distros and older versions on many.

I assume that dependency comes from cubeb but I did not verify it myself (other than seeing it's listed in their CMake).

If this is the issue with cubeb (#3776 and #3805), I think it might be an acceptable idea is to disable the sndio backend in cubeb for the time being (how come cubeb backends are not dynamically linked at runtime anyway? - although that's an upstream issue).

Calling people who touched cubeb backend: @darkf, possibly @jbeich

[darkf]

I don't see why they shouldn't be supported if available on a particular user's machine. Clearly it's a problem with Travis having sndio but building binaries that want it, so ideally Travis' config should disable these backends and only support a reasonable subset (Pulse+ALSA on Linux, AudioUnit on macOS for the 2 macOS users, WASAPI for Windows), not Citra proper.

[Fortich]

Try making a symbolic link

ln -T /usr/lib/libsndio.so.7.0 /usr/lib/libsndio.so.6.1

[JayFoxRox]

That would be a workaround. A horrible one at that, because it breaks your system and depending on your environment, could result in it not working on reboot. The name change suggests a change in API behaviour, so you can't just use the new version to replace the old one.
At least you should do LD_PRELOAD or get the file from some alternative repo or something.

A real fix would be what I suggested in my first post, confirmed by @darkf : disabling sndio for builds, because it seems to be a niche feature which is entirely optional anyway.

[darkf]

I did this in https://github.com/darkf/citra/pull/1 and I asked @chris062689 to test it as Travis didn't build artifacts and I don't have a Linux machine, but I didn't hear back.

[braiam]

Debian testing suffers the same situation.

[ghost]

Same issue on Ubuntu 18.10

[serovar]

Same on Fedora 29

[MLDamazigh]

Same on Ubuntu 19.04

[WuskyDingo]

Here's a solution for the folk on Non-LTS Ubuntu versions (and derivatives). For some reason, libsndio6.1 isn't on Non-LTS Ubuntu repos. So the easiest solution is just to download it from their LTS repo, and manually installing it.

Steps:
1) Download libsndio6.1_1.1.0-3_[platform here].deb from the 18.04 LTS Repo:

https://packages.ubuntu.com/bionic/libsndio6.1

_Make sure to download the one for your platform. x64 is amd64, Nintendo Switch is arm64, etc._

2) Install the deb with gdebi*

sudo gdebi libsndio6.1_1.1.0-3_[platform here].deb

*If you don't have gdebi, install it first with the following command:

sudo apt install gdebi

_Gdebi helps with automatically installing dependencies, if you're missing any for the deb you're installing._

Now try running ./citra-qt again. It'll launch!

Enjoy! :D

Can confirm this worked on Pop!_OS 19.04 (aka Ubuntu 19.04).

[JayFoxRox]

That's, again, only a workaround, not a solution.

We should not have to install ancient software (which is also why it's not in non-LTS) to run Citra.
Citra should disable this backend (or link it dynamically), as it has alternative backends which are supported much better by distributions.

I regret my Citra contributions, with some of the developments this project took, and the inability of the community to fix such issues after more than a year. The FOSS concept appears to fails here: nobody feels responsible.

[WuskyDingo]

I'm just trying to be helpful ;~;

[wwylele]

@JayFoxRox do you realize the normal linux binary has been hidden on the official website and replaced by flatpak for also about a year? I am not saying I totally like the flatpak solution, but this is an issue invisible to the majority of the community now. How do you expect people to take responsibility when there is no known problem.

[chris062689]

FYI - The official distribution method and recommended way of installing is flatpak, which is available here.
https://flatpak.citra-emu.org/

The flatpak build does have issues with AAC audio, but that's more of a licensing issue.

[chris062689]

@JayFoxRox Ancient software? Citra has always bound itself to the latest Ubuntu LTS release.

This is so we are not chasing an ever-moving target of updating our dependencies.

Tieing ourselves to stable versions of the library, especially with flatpak distribution, eases the maintenance burden.

[JayFoxRox]

Why is my post marked as off-topic? I clearly make a response to a previous post, and this issue as a whole.

do you realize the normal linux binary has been hidden on the official website and replaced by flatpak for also about a year?
[...]
FYI - The official distribution method and recommended way of installing is flatpak, which is available here.

I do see that the main download button goes to flatpak - but I don't want that, so I use the "Manual download" button instead. There's no comment on the download portion of the website that flatpak is the only supported release, either.

I don't consider this being "hidden".

How do you expect people to take responsibility when there is no known problem.

This issue has existed for over a year, and got 2 posts with rather poor workarounds (which need user intervention and might affect system stability) + 4 independent reports of the problem still existing.

This GitHub issue, makes this a "known problem". The issue has had a ping for at least one Citra Team member.

Ancient software? Citra has always bound itself to the latest Ubuntu LTS release.

I did not consider this. In that case, this issue should have gotten a response about that, or a removal of said backend should be considered (in Citra, or upstream in cubeb).
While backwards compatibility with LTS is good idea, it's still a bad solution if it breaks Citra for most other users.

---

If flatpak is considered the only supported release, or only LTS is supported as target platform, then that should be publicly documented on the website (is it? where?) and this issue should have been closed much earlier, citing that documentation.

[chris062689]

I agree it should be documented on the website. More than likely we can add it to the downloads page if the user is running Linux.

We currently only provide support for the latest Ubuntu LTS release. At this time, is 18.04.
Flatpak allows any supported Linux distribution to run Citra without having to worry about these dependency issues.