Please remove or make explicit the dependency on libgobject, libcairo, librsvg

[probonopd]

Getting lots of ERROR: appimage_register_in_system : Unable to load libgobject-2.0.so.

Is this dependency coming from libappimage? I don't remember having seen it in pre-libappimage days.

appimaged, continuous build (commit 2e34378), build 108 built on 2019-03-14 17:43:20 UTC

[probonopd]

Interestingly, this is contained in

sudo apt-get install libglib2.0-dev

Why on earth would we need a -dev package to run appimaged?

[probonopd]

Interestingly, a self-built libappimage does not show a dependency on libgobject-2.0.so:

me@host:~/libappimage/build$ ldd ./src/libappimage/libappimage.so
	linux-vdso.so.1 (0x00007ffeb23a7000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f14cc07b000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f14cbe77000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f14cbc5a000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f14cb8cc000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f14cb6b4000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f14cb2c3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f14cc618000)

However, inspecting it with strings does make it a likely candidate for having introduced this dependency "secretly":

me@host:~/libappimage/build$ strings ./src/libappimage/libappimage.so | grep goblibgobject-2.0.so
libgobject-2.0.so.0
libgobject-2.0.so.0.0

[probonopd]

In fact, there are even more "hidden dependencies":

me@host:~/libappimage/build$ strings ./src/libappimage/libappimage.so | grep -e  "^lib.*so.*"
libpthread.so.0
libdl.so.2
libz.so.1
libstdc++.so.6
libgcc_s.so.1
libc.so.6
libappimage.so.1.0
librsvg-2.so.2 # What about this? We cannot assume it to be everywhere
libcairo.so.2 # What about this? We cannot assume it to be everywhere
libgobject-2.0.so # What about this? We cannot assume it to be everywhere
libgobject-2.0.so.0 # What about this? We cannot assume it to be everywhere

The same is true for appimaged which uses libappimage internally:

me@host:~$ strings squashfs-root/usr/bin/appimaged | grep -e  "^lib.*so.*"
(...)
libstdc++.so.6
libgcc_s.so.1
(...)
librsvg-2.so.2 # What about this? We cannot assume it to be everywhere
libcairo.so.2 # What about this? We cannot assume it to be everywhere
libgobject-2.0.so # What about this? We cannot assume it to be everywhere

[probonopd]

In fact, it's even way worse than that. If we make the "hidden dependencies" to real dependencies, and then check with ldd, we see that libappimage and hence appimaged now depend on a whole lot of stuff indirectly:

# "Unhide" the "hidden dependencies" 
me@host:~/libappimage/build$ /isodevice/Applications/patchelf --add-needed librsvg-2.so.2 --add-needed libcairo.so.2 --add-needed libgobject-2.0.so ./src/libappimage/libappimage.so

# Check the real dependencies
me@host:~/libappimage/build$ ldd ./src/libappimage/libappimage.so
	linux-vdso.so.1 (0x00007ffe98b28000)
	libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f348923c000)
	libgobject-2.0.so => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so (0x00007f3488fe8000)
	librsvg-2.so.2 => /usr/lib/x86_64-linux-gnu/librsvg-2.so.2 (0x00007f3488db0000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3488b91000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f348898d000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3488770000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f34883e2000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f34881ca000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3487dd9000)
	libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f3487b34000)
	libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f34878ef000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f348763b000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f3487409000)
	libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f3487206000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3486fde000)
	libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f3486dd1000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f3486bc7000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f348688e000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f348667c000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3486474000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f34860d6000)
	libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f3485dc0000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f3485bb8000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f3485994000)
	libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f34855f6000)
	libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f34853e9000)
	libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f34851d3000)
	libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f3484f86000)
	libcroco-0.6.so.3 => /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3 (0x00007f3484d4b000)
	libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f348498a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3489998000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f3484758000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f3484554000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f348434e000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f34840dc000)
	libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f3483ed8000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f3483cb0000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3483a95000)
	libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007f3483841000)
	libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f34835a3000)
	libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f348339a000)
	libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f3482fe3000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3482dbd000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f3482ba8000)
	libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f348295b000)
	libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f348272e000)
	libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f3482527000)
	libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f348097e000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f3480777000)

[probonopd]

At the very least, the dependencies must be made explicit (so that they show up in ldd) so that tools like linuxdeploy and linuxdeployqt will have a chance to bundle the dependencies (e.g., here). We will have to see how large appimaged becomes then.

[probonopd]

https://artifacts.assassinate-you.net/artifactory/appimaged/travis-112/appimaged-x86_64.AppImage has 2.9 MB as opposed to 0.7 MB before. Do we think this is still acceptable? What functionality do we gain that was previously unavailable?