I’m looking into snap for the first time. How do snaps work for C/C++, where the binary will be different on each distro it is built for? (Due to different compilers, different versions of libc++/libstdc++, etc.)
Thanks,
Mohan
Hi,
With snapcraft you do not build for each release. Instead you build once and it will run anywhere. Specifically, right now there is a single base snap called “core” which is a minimal Ubuntu-style filesystem. All snaps are built against the libraries available in the core snap which are based on Ubuntu 16.04.
Once you compile your C or C++ code against libraries that are either provided by core (essentially libc only) or that you ship in your own snap filesystem your snap will be able to run anywhere that snapd is installed.
1 Like
Thank you for the quick and informative response!
How would it work if you needed to build libraries to ship to clients? Would they have to install snap and be tied to the “core” system as well?
Snap packaging isn’t really set-up to support sharing libraries with applications that aren’t also inside snap packages. If your clients’ apps are in snap packages then you should look at the content interface concept which allows your clients’ snaps to mount your snap into their directory structure and access any assets within your snap as though they were shipped in your clients’ snap directly. Currently the best example of this is the gnome-3-26-1604 snap which several other snaps use to provide a shared set of gnome platform libraries.
The alternative way to share libraries for snap packages is for you to not compile your library into a snap package but provide a download (it can be compiled) which your clients ingest via a dump part or a part that compiles your library specifically for their snap application.
If your clients aren’t shipping, or willing to ship, their apps as snaps then maybe snap packaging isn’t the best avenue for your particular use-case.
What exactly do you mean by “build libraries to ship to clients”?
If your application needs some custom libraries you can build those and include them as part of the app’s snap, it will find them there. If your need third-party libs that are available within the Ubuntu repos, all you need to do is list them under “build-packages” in snapcraft.yaml and it will pick them up automatically. This will work even if the user runs your snap on a system other than Ubuntu.
If you mean releasing libraries to developers in snap form, it’s not really designed for that. Have a look at packages like gnome-3-26 to see how they do it, but generally it may not be the right way to go.
If you mean releasing libraries to developers in snap form,
This. Thank you both.
PS. Going by what you both say, snap is a lot like docker but without the strict separation of host and guest? With “core” being like a Docker base image? Then a snap is like a docker image, and snapd like docker?
They’re not quite as analogous as that. The core snap and your application snaps are completely independent. With Docker the image is a layered stack, where with Snapcraft a snap is a single non-layered squashfs filesystem. In Docker the effect of using a base image is akin to copying it into your apps image file where a change in the base image will require your image to be rebuilt. With Snapcraft a change in the core snap will be able to roll-out without requiring your app to be rebuilt because the core snap is a completely separate filesystem which is bind mounted into your application’s view of the world but is independent. Snapd like Docker coordinates all the confinement and mounting of the applications’ filesystems and integrating the applications into your system such as by making graphical applications’ .desktop files available in the correct place and ensuring that place is loaded by the desktop environments. Snapd will also ensure that systemd services are created for applications which define the requirement for there to be one.