Several libraries from stage-packages missing despite proper LD_LIBRARY_PATH

[cjp256]

@prex

The stage-packages for my particular snap are put in the folder stage in my VM and the build-packages are just in their normal places in the VM (?).

Yes.

@prex

How does snapcraft know missing stage-packages if they are only used during runtime (otherwise the snap would probably not succeed). I got an error before from a missing library without snapcraft giving me that hint during the build. Why is this different with libpsm?

Snapcraft will do its own dependency resolution. It’s not perfect, but that’s why they are only presented as warnings. The difference in behavior you are seeing is because snapcraft will resort to scanning the entire snap for libraries, assuming the snap author setup the correct LD_LIBRARY_PATH for runtime.

@prex

Where are these stage-packages missing? In $SNAPCRAFT_STAGE or $SNAPCRAFT_PRIME? And how is $SNAP related to these?

$SNAP is a runtime variable set in the process of the running snap. $SNAPCRAFT_STAGE,PRIME are build-time variables.

@prex

What do I need to symlink? Files inside $SNAPCRAFT_STAGE, $SNAPCRAFT_PRIME or $SNAP (which I don’t know where to find)?

Maybe try something like this, using a relative symlink at build-time:

parts:
  <part>:
    override-build: |
      snapcraftctl build
      ln -sf ../libpsm1/libpsm_infinipath.so.1.16  $SNAPCRAFT_PART_INSTALL/usr/lib/x86_64-linux-gnu/libpsm_infinipath.so.1

@prex

Why is the LD_LIBRARY_PATH necessary when I need to symlink anyway? The LD_LIBRARY_PATH obviously doesn’t save me from the error message during the build.

If the source symlink is correct, and it resides in your library path, you won’t need to modify LD_LIBRARY_PATH.

For example, if you added $SNAP/usr/lib/libpsm1 to your LD_LIBRARY_PATH, the symlink example above would be: ln -sf libpsm_infinipath.so.1.16 $SNAPCRAFT_PART_INSTALL/usr/lib/libpsm1/libpsm_infinipath.so.1

Hope that helps!