linuxdeploy should work iff ldd -d executable manages to (recursively) locate all dependencies, right? I found an example where it does not.
I've upgraded my development environment from Ubuntu 16 -> 18 and thereby also upgraded the default compiler gcc 5 -> 7. Everything's fine, except that apparently gcc has changed the behaviour of -rpath somewhat: basically where I previously had RPATH in my binaries I now have RUNPATH.
This is fine, since RPATH was deprecated long ago, but the difference is that RUNPATH is not inherited, and this leads to an issue with linuxdeploy.
My binary looks like this:
$ readelf -d example | grep path
0x000000000000001d (RUNPATH) Library runpath: [...:/home/user/Qt/5.12.3/gcc_64/lib]
ldd locates all dependencies just fine:
$ ldd -d example | grep "not found"
# empty
and I can run the application from the terminal just fine without specifying LD_LIBRARY_PATH.
However, linuxdeploy fails:
$ QML_SOURCES_PATHS=/path/to/resources/qml ./linuxdeploy-x86_64.AppImage -v0 --appdir Example.AppDir -e Example.AppDir/usr/bin/example -i Example.AppDir/example.png -d Example.AppDir/example.desktop --plugin=qt
... lots of output ...
Deploying dependencies for ELF file /home/user/Qt/5.12.3/gcc_64/lib/libicui18n.so.56
DEBUG: Invalid ldd output: linux-vdso.so.1 (0x00007ffccddc0000)
ERROR: Could not find dependency: libicuuc.so.56
ERROR: Failed to deploy dependencies for existing files
Indeed, when I check ldd by hand on just that dependency, what I get is:
$ ldd -d ~/Qt/5.12.3/gcc_64/lib/libicui18n.so.56 | grep found
libicuuc.so.56 => not found
libicudata.so.56 => not found
However, in my executable libicuuc.so.56 and libicudata.so.56 are definitely locatable:
$ ldd -d Example.AppDir/usr/bin/example | grep libicu
libicui18n.so.56 => /home/user/Qt/5.12.3/gcc_64/lib/libicui18n.so.56 (0x00007fb31a2fc000)
libicuuc.so.56 => /home/user/Qt/5.12.3/gcc_64/lib/libicuuc.so.56 (0x00007fb319f44000)
libicudata.so.56 => /home/user/Qt/5.12.3/gcc_64/lib/libicudata.so.56 (0x00007fb318561000)
I'm not entirely sure how ldd actually resolves this library, but maybe somewhere down the line in Qt there might still be an RPATH being set or so?
TL;DR: linuxdeploy calls ldd directly on a dependency, which fails, while calling ldd on the executable that I'm trying to bundle resolves all dependencies recursively just fine.
linuxdeployshould work iffldd -d executablemanages to (recursively) locate all dependencies, right? I found an example where it does not.I've upgraded my development environment from Ubuntu 16 -> 18 and thereby also upgraded the default compiler gcc 5 -> 7. Everything's fine, except that apparently gcc has changed the behaviour of
-rpathsomewhat: basically where I previously had RPATH in my binaries I now have RUNPATH.This is fine, since RPATH was deprecated long ago, but the difference is that RUNPATH is not inherited, and this leads to an issue with
linuxdeploy.My binary looks like this:
lddlocates all dependencies just fine:and I can run the application from the terminal just fine without specifying
LD_LIBRARY_PATH.However,
linuxdeployfails:Indeed, when I check
lddby hand on just that dependency, what I get is:However, in my executable
libicuuc.so.56andlibicudata.so.56are definitely locatable:I'm not entirely sure how
lddactually resolves this library, but maybe somewhere down the line in Qt there might still be an RPATH being set or so?TL;DR: linuxdeploy calls
ldddirectly on a dependency, which fails, while callinglddon the executable that I'm trying to bundle resolves all dependencies recursively just fine.