I’m working on a snap package for a Go program. The documentation hints that shared libraries are automatically discovered via ldd and added to the package, but this did not seem to work in my case, so I added my dependencies to stage-packages:
error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory
What’s weird about this is that I don’t even use libgcrypt, instead it’s a dependency of webkitgtk. I tried adding libgcrypt to stage-packages and now I get:
error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
I could probably keep doing this until I’ve covered all 500-something dependencies, but that’s surely not how it’s intended to work, right?
Yes and no; this is hidden at the moment and should be exposed to the user so they know what is going on.
A long time ago, in a galaxy far far away, someone created this list (@mvo I believe you gave me the explanation of the reason for this list back then).
In that list, there are packages like libc6 which is where the dependency chain is cut to avoid bringing it in (it will be brought in if explicitly listed though). While libc6 may be obvious (and to be fair, it may not to everyone), there are other libraries in that list, such as libgcrypt20.
So we need to do two things here; provide a summary of what has been skipped and more importantly, explain why it is being skipped. I am mostly certain this list comes from packages that were in core back then and that list has changed somewhat from when it was first crafted all the way to when 16 was released.
Here’s the issue for _tracking` purposes, let’s keep having a discussion here if needed
That makes sense, but where are these libraries supposed to come from instead? The host system? Definitely does not work for me with confinement: strict on Solus, I do have libgcrypt.so.20 but still get the error.
well, they are definitely there, the question is why are they not in your LD_LIBRARY_PATH at runtime or does your app (being go) perhaps ignore this var or some such … ?
I just set up a fresh Ubuntu VM and did a snapcraft cleanbuild and it actually worked! I think build.snapcraft.io borked the build, it even appears to be completely stuck now, only armhf is building.
For the record, the reproduction steps are as simple as:
$ sudo snap install --edge blockforge
$ blockforge
/snap/blockforge/17/bin/blockforge: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
But this will hopefully be fixed with the next rebuild.
