Skip to content

Dependencies of dependencies not found while ldd does find them #76

@haampie

Description

@haampie

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions