Library linter

doc
1

The library linter is a Snapcraft linter that verifies whether any ELF file dependencies, typically libraries, are missing from a snap. It also verifies if any libraries are included in a snap but unused.

See Disable a linter for details on how to stop this linter from running.

How the linter helps

If a snapped application depends on libraries neither provided by the base system, nor included as a dependency, the snap may execute in an incorrect or unpredictable way. The library linter issues a warning if a missing dependency is detected.

Snap package size can be reduced by removing extra libraries that are not used by the applications in the snap. The library linter issues a warning if unused libraries are detected.

Linter warnings

The library linter issues a warning if:

  • An ELF file is missing any dependencies.
  • An ELF file has unused dependencies.

Example warnings

This terminal output shows two missing libraries (libcaca and libslang) and one unused library (libpng16).

Running linter: library
Lint warnings:
- library: my-app: missing dependency 'libcaca.so.0'.
- library: my-app: missing dependency 'libslang.so.2'.
- library: libpng16.so.16: unused library 'usr/lib/x86_64-linux-gnu/libpng16.so.16.37.0'.

Fix flagged issues

The following guidelines describe how to address issues flagged by the linter.

To resolve a missing dependency:

  • Add the missing package to the part’s stage-packages key.

To resolve an unused library:

Library type Resolution
Dynamic linking If the stage-packages key of the part contains the unused library and no other entries, remove the library from the key. If the library contains other assets the snap needs, then instead move it to the part’s stage key and prefix it with a minus sign (-). It’s then excluded from the stage step of the build.
Static linking Static linking libraries must only be present at build time. So, the part should list the library in its build-package key, not stage-package. Again, if the library contains other necessary assets for the snap, then move it into the part’s stage key and prefix it with a minus sign.
Dynamic loading Snapcraft may falsely flag dynamic loading libraries as unused. In this case, don’t change its declaration in the recipe. Moving or removing it has a high risk of causing your app to malfunction at runtime. Instead, list it in the lint.ignore.<linter> key to suppress the warning for this library.

See Build and staging dependencies for further details about the stage-packages key.

4 Likes
2

It’d be useful to also check to see if the snap contains libraries that shadow libraries from the base snap or content snaps. That’s something that has bitten us a few times in the past.

One example was the snap-store snap. At one point it was shipping libatk, shadowing the copy from the gnome platform snap. There were other libraries within the platform snap that linked with libatk, but weren’t shadowed by snap-store. When an update was pushed to the platform snap that upgraded libatk and some other libraries, it broke snap-store because those other libraries didn’t work with the old libatk.

I’m sure there are cases where shadowing is intended, but maybe it is better to get people to be explicit about it and silence the linter for those specific cases.

1 Like
3

I would like to ask whether this may generate false positives such as a program loading the shared libraries only in runtime.

Also, how to silent the warning when false positives are occurred, thanks!

4

If you have dlopen() calls or a similar mechanism in your code then yes, you will get a false positive.

See this page for disabling them.

1 Like