Some AppImages fail on Fedora 25 with libXss.so.1 error

[probonopd]

Some AppImages, e.g., the official Etcher one, fail on Fedora-Workstation-Live-x86_64-25-20161105.n.0.iso 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. it would be nice if such basic, tiny libraries would come preinstalled. Can we write a replacement dummy libXss.so.1 that just does nothing?

[darealshinji]

Can we write a replacement dummy libXss.so.1 that just does nothing?

Like this?

// gcc -s -shared -Wl,-soname,libXss.so.1 scrnsaver.c -o libXss.so.1
#include <X11/Xlib.h>
typedef unsigned long ulong;
typedef unsigned int uint;
typedef struct { Window window; int state; int kind; ulong til_or_since; ulong idle; ulong eventMask; } XScreenSaverInfo;
Bool XScreenSaverQueryExtension(Display *dpy, int *event_base_return, int *error_base_return){}
Status XScreenSaverQueryVersion(Display *dpy, int *major_version_return, int *minor_version_return){}
XScreenSaverInfo *XScreenSaverAllocInfo(void){}
Status XScreenSaverQueryInfo(Display *dpy, Drawable drawable, XScreenSaverInfo *saver_info){}
void XScreenSaverSelectInput(register Display *dpy, Drawable drawable,  ulong mask){}
void XScreenSaverSetAttributes(Display *dpy, Drawable drawable, int x, int y, uint width, uint height,
  uint border_width, int depth, uint class, Visual *visual, ulong valuemask, XSetWindowAttributes *attributes){}
void XScreenSaverUnsetAttributes(register Display *dpy, Drawable drawable){}
Status XScreenSaverRegister(Display *dpy, int screen, XID xid, Atom type){}
Status XScreenSaverUnregister(Display *dpy, int screen){}
Status XScreenSaverGetRegistered(Display *dpy, int screen, XID *xid, Atom *type){}
void XScreenSaverSuspend(Display *dpy, Bool suspend){}

[probonopd]

@darealshinji bravo, the dummy libXss.so.1 seems to do the job! :+1:

I would like to see similar dummy libraries for other libraries such as libkrb.so -- can you give instructions how to do this?

Note to self: sudo apt-get install libx11-dev

[lurch]

Do these dummy libraries need to be made optional (individually), in case the packaged app does rely on functions in a particular library?

[probonopd]

Since the don't actually do anything, they can make applications that depend on a given library launch (no more "unresolved symbols") but the functionality provided by that library will not be available to the application.

[lurch]

but the functionality provided by that library will not be available to the application.

Yeah, that's what I meant - if an app does rely on functionality in a particular library, then there ought to be an option in the appimage-creation-script to not create a dummy proxy for that library (if/when this feature gets integrated into the appimage-creation-script).

[darealshinji]

I'd like to point out that if libXss is not part of the base on some desktop distributions (which I find weird), it should probably be provided with the AppImage. By the way, if you want to add libXss you don't need to build a fake library. It's small and MIT licensed.

[lurch]

Does this partially overlap with #173 ?

i.e. maybe the appimage-creation-script could include all libraries that the bundled app relies on, but only use the 'bundled' versions of each library when that library doesn't already exist on the host system? Or maybe that'd simply make the appimages too big?

[darealshinji]

173 is basically about backporting C++11 or C++14 apps to old distros.

libXss is not on the blacklist, so I think this library should be bundled with some others.

[probonopd]

I'd like to point out that if libXss is not part of the base on some desktop distributions (which I find weird), it should probably be provided with the AppImage

You may be right there... keep it simple and stupid. Can we be sure that if we bundle it, it doesn't break when it's mixed with other libX* libraries? This is the reason why I was hesitant of doing this in the first place. But then, why do all apps need a screensaver library...

[probonopd]

CentOS 7 is also affected, https://github.com/appium/appium-desktop/issues/34#issuecomment-281840789