Cross-distro problems with a classic snap dependent on libcurl

I’ve discovered a rather problematic issue with the dub classic snap defined here:

The dub application is a package/build manager for the D programming language, and it uses libcurl to download package data. It does this via the wrapper in the D standard library, which takes a list of possible different libcurl dynamic library names, and attempts to load each in turn using dlopen until it either succeeds or exhausts the list:

Currently the snap package does not include libcurl in its stage-packages, but (as a classic snap) depends on the presence of libcurl on the host system. This seems to work fine on 16.04 and earlier, but the app fails to find any appropriate libcurl on 18.04. There’s clearly a risk that the same thing will happen on other non-Ubuntu distros as well.

There seem to be two broad possibilities here:

  • the design principle is OK but the snap package isn’t searching the right library paths on the 18.04 host

  • the snap package should bundle libcurl using stage-packages or some other mechanism

W.r.t. the former, searching for libcurl on 16.04:

$ ldconfig -p | grep curl
	libcurl.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcurl.so.4
	libcurl-gnutls.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
	libcurl-gnutls.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so

… reveals something not substantially different from on 18.04:

$ ldconfig -p | grep curl
    libcurl.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcurl.so.4
    libcurl-gnutls.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4

… so it’s not clear why the library on the host system would be found in the former case and not in the latter.

When I tried bundling libcurl using stage-packages, dub still failed to find it – I presume that this might again comes down to what paths are being searched for the libraries.

Any advice on how to address this, or to track down the problem more precisely? I would consider setting LD_LIBRARY_PATH but from some searching around it looks like this is frowned on for snaps.

I’d have thought setting LD_LIBRARY_PATH for that specific app within the snap would be fine and sensible. I suspect you might get unintended consequences if it was changed for the main compiler app, though.

1 Like

Classic or not, if your snap depends on a library in the system, it is a broken snap.

1 Like

This is what I did in the end. Note that no compiler app is bundled inside this snap; I just build one as a bootstrap to build the app itself.

Probably I could use build-snaps instead these days but it keeps the package nicely independent to do it like this.

Agreed – this experience clearly shows it. However I am curious why it worked on a 16.04 host and failed on an 18.04 one, when libraries with the same names were in the same locations.

However, I’ve now released a fixed version bundling libcurl using stage-packages.

Thanks to both of you for thoughts and advice! :slight_smile:

there was an ABI change between those two glibcs.

1 Like