I’ve got a snap that’s being built by build.snapcraft.io for both amd64 and i386. When I install it locally, it works great. When I install it inside of LXD on (amd64) Jenkins, it fails to run the executable, even though it’s there:
+ ls -lath /snap/juju-helpers/7/bin/juju-bundle
-rwxr-xr-x 1 root root 3.7M Jun 13 14:24 /snap/juju-helpers/7/bin/juju-bundle
/snap/juju-helpers/7/bin/juju-bundle: No such file or directory
It may be confusing but the ENOENT error code is also reported when the dynamic interpreter is not found. Perhaps it is that? Can you look at readelf -e /path/to/executable and see what the lines that say:
INTERP 0x00000000000002a8 0x00000000000002a8 0x00000000000002a8
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
@zyga-snapd: Thanks for the response. This is what readelf gave me:
[Requesting program interpreter: /lib/ld-linux.so.2]
+ ls -lath '/lib/ld-linux*'
ls: cannot access '/lib/ld-linux*': No such file or directory
The ldd output is interesting. On my laptop, it shows a number of i386 libraries, but on Jenkins it shows not a dynamic executable.
On a related note, I’ve specified several different architectures in my snapcraft.yml, but it looks like only one is getting built (i386 if all arches are specified, amd64 if i386 is removed). Is that intentional on the part of build.snapcraft.io?
ldd is a script, it doesn’t really do good error checking. It just meant it didn’t work correctly. Use readelf -d to see which libraries you really link to. Those can recursively link to more libraries and can even dynamically link to libraries via dlopen. For understanding dlopen it is good to use ltrace (outside of the confinement), e.g. with ltrace -e dlopen+dlmopen+dlclose+dlsym+dlinfo+dlerror /path/to/binary.