Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update excludelist: removing libgdk-x11-2.0.so.0 per #145 #146

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

fusion809
Copy link

Per title, removing libgdk-x11-2.0.so.0 from excludelist per issue #145.

@probonopd
Copy link
Member

probonopd commented Nov 22, 2016

Rather than just deleting it, please comment it out and add a comment describing why it cannot be assumed to be part of each target system. Thanks!

Isn't this part of GTK+ 2 which we assume to be part of the base system?

@fusion809
Copy link
Author

fusion809 commented Nov 22, 2016

Well it wasn't part of Fedora 24, so if it is part of the assumption, it's a faulty assumption, rofl. This is the GNOME edition of Fedora 24 too, so of all desktop environments one would assume it'd be the one to provide this library if it is a GTK+ 2 one. I'm working on the edit.

@fusion809
Copy link
Author

Done.

@probonopd
Copy link
Member

Could it be that a similarly-but-slightly-differently-named file exists on Fedora? Maybe we could symlink that instead? I still think this is a core part of GTK+ 2.0...

@fusion809
Copy link
Author

fusion809 commented Nov 22, 2016

You're right, except it's not similarly named it's identically named:

$ find /usr/lib64 -name "libgdk-x11*"
/usr/lib64/libgdk-x11-2.0.so.0
/usr/lib64/libgdk-x11-2.0.so.0.2400.31
/usr/lib64/libgdk-x11-2.0.so

@probonopd
Copy link
Member

So, why doesn't it use it then? Why should we bundle another one?

@fusion809
Copy link
Author

Don't know. But it causes this error, maybe it's related to the specific version of this library? Or maybe it's because it's looking for this library in /lib64 instead of /usr/lib64.

@probonopd
Copy link
Member

Please run with LD_DEBUG=libs ./the.AppImage and look for errors. Or sudo strace -eopen -f the.AppImage

@fusion809
Copy link
Author

LD_DEBUG=libs ./<AppImage> on Fedora 24 gave: http://paste2.org/4J7swGXk. strace gave http://paste2.org/Ph6558m9.

@fusion809
Copy link
Author

Based on the debug libs output I think I am right, the library provided by Fedora is a different version to that required by the AppImage.

@probonopd
Copy link
Member

Are you sure that you ran the strace command with sudo?

@probonopd
Copy link
Member

Based on the debug libs output I think I am right, the library provided by Fedora is a different version to that required by the AppImage.

Looking at which output?

@fusion809
Copy link
Author

first comment no, didn't realize it was necessary, one sec I'll do that: http://paste2.org/Ph6558m9. Second comment based on:

  2173:	find library=libgdk_pixbuf-2.0.so.0 [0]; searching
 2173:	 search path=/tmp/.mount_w2XqD4/usr/bin/../lib		(RPATH from file /tmp/.mount_w2XqD4/usr/bin/geany)
 2173:	  trying file=/tmp/.mount_w2XqD4/usr/bin/../lib/libgdk_pixbuf-2.0.so.0
 2173:	 search path=./lib/tls/x86_64:./lib/tls:./lib/x86_64:./lib:./lib/i386-linux-gnu/tls/x86_64:./lib/i386-linux-gnu/tls:./lib/i386-linux-gnu/x86_64:./lib/i386-linux-gnu:./lib/x86_64-linux-gnu/tls/x86_64:./lib/x86_64-linux-gnu/tls:./lib/x86_64-linux-gnu/x86_64:./lib/x86_64-linux-gnu:./lib32/tls/x86_64:./lib32/tls:./lib32/x86_64:./lib32:./lib64/tls/x86_64:./lib64/tls:./lib64/x86_64:./lib64		(LD_LIBRARY_PATH)
 2173:	  trying file=./lib/tls/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/tls/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/i386-linux-gnu/tls/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/i386-linux-gnu/tls/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/i386-linux-gnu/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/x86_64-linux-gnu/tls/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/x86_64-linux-gnu/tls/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/x86_64-linux-gnu/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib32/tls/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib32/tls/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib32/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib32/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib64/tls/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib64/tls/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib64/x86_64/libgdk_pixbuf-2.0.so.0
 2173:	  trying file=./lib64/libgdk_pixbuf-2.0.so.0
 2173:	 search cache=/etc/ld.so.cache
 2173:	  trying file=/lib64/libgdk_pixbuf-2.0.so.0

@fusion809
Copy link
Author

Oops no I mean this output:

      2173:	find library=libgdk-x11-2.0.so.0 [0]; searching
      2173:	 search path=/tmp/.mount_w2XqD4/usr/bin/../lib		(RPATH from file /tmp/.mount_w2XqD4/usr/bin/geany)
      2173:	  trying file=/tmp/.mount_w2XqD4/usr/bin/../lib/libgdk-x11-2.0.so.0
      2173:	 search path=./lib/tls/x86_64:./lib/tls:./lib/x86_64:./lib:./lib/i386-linux-gnu/tls/x86_64:./lib/i386-linux-gnu/tls:./lib/i386-linux-gnu/x86_64:./lib/i386-linux-gnu:./lib/x86_64-linux-gnu/tls/x86_64:./lib/x86_64-linux-gnu/tls:./lib/x86_64-linux-gnu/x86_64:./lib/x86_64-linux-gnu:./lib32/tls/x86_64:./lib32/tls:./lib32/x86_64:./lib32:./lib64/tls/x86_64:./lib64/tls:./lib64/x86_64:./lib64		(LD_LIBRARY_PATH)
      2173:	  trying file=./lib/tls/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/tls/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/i386-linux-gnu/tls/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/i386-linux-gnu/tls/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/i386-linux-gnu/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/i386-linux-gnu/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/x86_64-linux-gnu/tls/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/x86_64-linux-gnu/tls/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/x86_64-linux-gnu/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib32/tls/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib32/tls/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib32/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib32/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib64/tls/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib64/tls/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib64/x86_64/libgdk-x11-2.0.so.0
      2173:	  trying file=./lib64/libgdk-x11-2.0.so.0
      2173:	 search cache=/etc/ld.so.cache
      2173:	  trying file=/lib64/libgdk-x11-2.0.so.0

@fusion809
Copy link
Author

While we're on the topic of blacklisted libraries libselinux.so.1 may be necessary as Arch Linux gives the error (according to geany/geany#1303):

zenity, kdialog, Xdialog missing. Skipping ./bin//geany.wrapper.
/tmp/.mount_3N7xOv/usr/bin/geany: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory

@b4n
Copy link

b4n commented Nov 22, 2016

#145 (comment)

rather than including libgdk-x11, I guess X11 libs should be excluded (and here yours override the system's, and miss that symbol the system's gdk-x11 requires)

@probonopd
Copy link
Member

@b4n may be right here - needs to be verified by experimentation on different distros.

@darealshinji
Copy link
Contributor

I also think that very common X11 libs should be excluded by default (libx11, libext6; but not the libxcb* stuff or "rare" libraries that are usually not installed or even dropped by some distros). I would also exclude glib2 and gtk+-2 and their companion libraries (libatk, libgdk*, ...), as those libraries are normally installed by default and they have a very stable API.
Is there a mechanism to easily override or modify the blacklisted libraries and/or Debian packages if that's required or wanted for a certain AppImage?

@probonopd
Copy link
Member

I also think that very common X11 libs should be excluded by default (libx11, libext6; but not the libxcb* stuff or "rare" libraries that are usually not installed or even dropped by some distros).

Do you know which of these can really be expected to (still) be part of each distro? (even distros using Wayland?)

I would also exclude glib2 and gtk+-2 and their companion libraries (libatk, libgdk*, ...), as those libraries are normally installed by default and they have a very stable API.

You may be right there. Feel free to send a PR but include the rationale as comments in the exclude(deb)list.

Is there a mechanism to easily override or modify the blacklisted libraries and/or Debian packages if that's required or wanted for a certain AppImage?

No, by design. So that we are forced to learn and share the insights (i.e., if we change the blacklist all AppImages benefit from it).

@b4n
Copy link

b4n commented Dec 4, 2016

but not the libxcb* stuff

Well, on my Debian unstable, libcairo2, which is a dependency of GTK2 and 3 among a lot of things, depends on libxcb, libxcb-shm and libxcb-render.
Basically, I see not much reason to not exclude everything that is a direct dependency of one the the otherwise excluded things.

@b4n
Copy link

b4n commented Dec 4, 2016

Do you know which of these can really be expected to (still) be part of each distro? (even distros using Wayland?)

I don't know, but I'm kind of afraid that either X is an indirect dependency of the app (e.g. through GTK), or the app is likely not to work on Wayland anyway.

@darealshinji
Copy link
Contributor

Well, on my Debian unstable, libcairo2, which is a dependency of GTK2 and 3 among a lot of things, depends on libxcb, libxcb-shm and libxcb-render.
Basically, I see not much reason to not exclude everything that is a direct dependency of one the the otherwise excluded things.

It's better to include the libxcb* stuff because I've already experienced issues with apps being compiled on Ubuntu 12.04 that didn't work on newer versions because of a soname version bump of a libxcb* library.

Taking a quick look into the Ubuntu repositories[1] also reveals that not all libxcb libraries are available on all distros:
libxcb-present0: >= 14.04
libxcb-sync0: 12.04
libxcb-sync1: >= 14.04
libxcb-util0: <= 14.04
libxcb-util1: >= 16.04
...

@probonopd
Copy link
Member

Basically, I see not much reason to not exclude everything that is a direct dependency of one the the otherwise excluded things.

That kinda makes sense, but how do we know that the same stuff is not a dependency of some app directly, i.e., not through "the otherwise excluded things"?

@darealshinji
Copy link
Contributor

Here's a first list based on what's installed on my system and what's available since Ubuntu 12.04: https://gist.github.com/darealshinji/21f368ddb61f4d3cfa303e228bb0e9db

It would of course be a good idea to check if these are all available by default on Live CDs of other distros.

@probonopd
Copy link
Member

saiarcot895/chromium-ubuntu-build#12 (comment) might be affected by this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants