Etcher: Fails to run, libXss.so.1 missing on Fedora 25

[probonopd]

• Etcher version: 1.0.0 Beta 16
• Operating system and architecture: Fedora-Workstation-Live-x86_64-25-20161105.n.0.iso
• Do you see any meaningful error information on DevTools?

Fails to run with:

error while loading shared libraries: libXss.so.1: 
cannot open shared object file: No such file or directory

As a workaround, sudo yum install libXScrnSaver solves this.

[lurch]

I think this dependency on libXScrnSaver (which seems like a strange dependency for a disk-flasher to have!) might be a side-effect of the AppImage packaging process? (and I wonder if that in turn is fixed by appimagetool ?)

Running strace against Etcher-run-by-electron shows no libXss.so.1 dependency, but running strace against Etcher-run-by-AppImage does show a libXss.so.1 dependency.

[probonopd]

Yes, I assume that _some_ library/ies that are bundled inside the AppImage have a dependency on libXss.so.1.

[jviotti]

Hey there,

@probonopd So is this something that needs to be handled by the AppImages project? If so, is there anything we can do to help?

and I wonder if that in turn is fixed by appimagetool ?

I'll keep an eye for this when I get a chance to test appimagetool.

[probonopd]

I haven't quite figured out yet where this (indirect) dependency is coming from. Doesn't seem to affect all AppImages.

[lurch]

Would it be worth changing all the programs used to run the AppImage to be statically compiled? (i.e. have no run-time library dependencies)

[jviotti]

It seems that this dependency comes from Electron. We actually maintain a list of Electron pre-requisites here: https://github.com/resin-io/etcher/blob/master/docs/USER-DOCUMENTATION.md#electron-specific, and xscrnsaver is listed there.

I'm closing this since I don't think we can do much about it, apart from pointing users to our docs to make sure they have all the required libraries.

[probonopd]

See this for a potential solution, what do you think about it?

[jviotti]

So we would include the dummy library in the package itself? I'm happy to give this a go today. I do wonder if we should approach the Electron guys, and see if we can fix this by not making Electron depend on it if its really not being used.

[probonopd]

Yes, the idea is to include the dummy library in the AppImage. This makes it load the dummy library and be happy. If we want to be super fancy, the dummy library could be loaded and check whether the real library is there, and call that in case it is...

[MasterGeekMX]

Sorry for commenting on a closed issue, but I have this issue on Fedora 29, using the Fedora/RHEL repository. Curiously, I have installed libXScrnSaver, and I tried $sudo dnf reinstall libXScrnSaver and nothing.

[MasterGeekMX]

I think I found a solution.

$ sudo dnf install libXScrnSaver-devel

Fedora reports libXScrnSaver as installed, but searching the repos I found libXScrnSaver-devel, and installing it worked, but curiously it also installed a dependency: libXScrnSaver itself!