c++cmakeinstallationshared-librariessnapcraft

Install shared library using snap


I have project, that is build by cmake and I want package with snap. Project includes executable and library (lets call it a and liba).

My snapcraft.yaml file looks like:

name: a
version: "0.9"
summary: xyz
description: xyz
grade: devel # must be 'stable' to release into candidate/stable channels
confinement: strict

apps:
  a:
    command: a

parts:
  a:
    plugin: cmake
    source: ./a.zip
    filesets:
      manpages: [ usr/share/man ]

In CMake, a depends on liba (in fact a is just "wrapper" of liba for use in bash scripts). When I build project with Snapcraft and install that package (installing as --dangerous), running command a from terminal works fine. But when I try to build application dependent on liba (using gcc), i got problem that ends with "/usr/bin/x86_64-linux-gnu-ld: cannot find -la" error message. First of all I have to include headers even if they have been installed into system default include directory using "-I/snap/a/current..." (I understand that snap install files into /snap/ directory, but maybe I'm just doing something wrong with snapcraft.yaml). Then I get message from ld above.

I'm totally new in snap packages, this is my first project. Is there possibility to install liba as system library (visible while building with gcc, using includes from system default directory)?

Maybe it would help split a and liba into different packages with a build-dependent on liba, but I'm not sure it will help with shared library installation problem.

Do you have some experience with this problem? Any advice? Thanks for answers.


Solution

  • I'm afraid snaps aren't really well-suited to what you're trying to do. They're great for end-user applications (e.g. the wrapper that makes the lib useful in scripts), but by design they're isolated from the rest of the system. It's possible to ship libraries in them for use from other applications, but those applications will need to look for libs and headers somewhere in /snap/<snap name>/current/, which is definitely not on the default search path.

    Note that you can ship libraries via a snap for use in other snaps via the content interface. I suggest avoiding it if you can, though; in my experience it's tremendously complex and fragile.