automatic ldd resolution fails with pulse

[Harald Sitter]

This is a bit of a special thing and it may well be not solvable.

We (KDE) are building a content snap with all our core libraries. To then build aginst libraries in this content snap we also create a tarball of the stage of the content snap (i.e. a tar containing every libray and header pertaining to the content snap).

To consume this one would have a dummy 'dump' part that uses the tarball as source. This works for the most part. It does however not work for pulseaudio. Specifically usr/lib/x86_64-linux-gnu/libpulse.so.0 needs usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so (note the subdir). Since we have both in the content snap and the associated dev tarball, a consumer should not need to install this, ld however falls flat on the face.

In a build environment libpulse0 would not be a stage-package, as such not installed in the system, and thus ld won't be able to resolve pulsecommon (supposedly because of the subdir).

Causes errors like this while trying to link a cmake project:
/usr/bin/ld: warning: libpulsecommon-8.0.so, needed by /var/lib/jenkins-slave/nci/workspace/kruler-release_amd64.snap/stage/usr/lib/x86_64-linux-gnu/libpulse.so.0, not found (try using -rpath or -rpath-link)
/var/lib/jenkins-slave/nci/workspace/kruler-release_amd64.snap/stage/usr/lib/x86_64-linux-gnu/libpulse.so.0: undefined reference to `pa_smoother_resume'

[Sergio Schvezov (sergiusens)]

El 31 oct. 2016 10:40 AM, "Harald Sitter" <email address hidden>
escribió:
>
> Public bug reported:
>
> This is a bit of a special thing and it may well be not solvable.
>
> We (KDE) are building a content snap with all our core libraries. To
> then build aginst libraries in this content snap we also create a
> tarball of the stage of the content snap (i.e. a tar containing every
> libray and header pertaining to the content snap).

This is the current recommended way to this. We went over it at the last
Sprint. There are some good things coming to make this better by the way
like parts caching.

> To consume this one would have a dummy 'dump' part that uses the tarball
> as source. This works for the most part. It does however not work for
> pulseaudio. Specifically usr/lib/x86_64-linux-gnu/libpulse.so.0 needs
> usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so (note the
> subdir). Since we have both in the content snap and the associated dev
> tarball, a consumer should not need to install this, ld however falls
> flat on the face.
>
> In a build environment libpulse0 would not be a stage-package, as such
> not installed in the system, and thus ld won't be able to resolve
> pulsecommon (supposedly because of the subdir).
>
> Causes errors like this while trying to link a cmake project:
> /usr/bin/ld: warning: libpulsecommon-8.0.so, needed by
/var/lib/jenkins-slave/nci/workspace/kruler-release_amd64.snap/stage/usr/lib/x86_64-linux-gnu/libpulse.so.0,
not found (try using -rpath or -rpath-link)
>
/var/lib/jenkins-slave/nci/workspace/kruler-release_amd64.snap/stage/usr/lib/x86_64-linux-gnu/libpulse.so.0:
undefined reference to `pa_smoother_resume'

This is indeed an issue and we do have a task/action in our spring notes to
not ldd crawl items that are in stage.

[Lucy Llewellyn (lucyllewy)]

This also affects linking against a library which then links to a library in `usr/local/lib` for example.

In building supertuxkart I'm hitting this issue where I have snapcraft do the following:
- build libopenh264 and stage to usr/local/lib
- build libopenglrecorder against libopenh264 from stage/usr/local/lib staging into usr/lib/$ARCH_TRIPLET
- build supertuxkart against libopenglrecorder from stage/usr/lib/$ARCH_TRIPLET

the build fails to link supertuxkart to libopenglrecorder with the similar message:

/usr/bin/ld: warning: libopenh264.so.4, needed by /root/build_supertuxkart/stage/usr/lib/x86_64-linux-gnu/libopenglrecorder.so, not found (try using -rpath or -rpath-link)
/root/build_supertuxkart/stage/usr/lib/x86_64-linux-gnu/libopenglrecorder.so: undefined reference to `WelsCreateSVCEncoder'
/root/build_supertuxkart/stage/usr/lib/x86_64-linux-gnu/libopenglrecorder.so: undefined reference to `WelsDestroySVCEncoder'
collect2: error: ld returned 1 exit status
CMakeFiles/supertuxkart.dir/build.make:10654: recipe for target 'bin/supertuxkart' failed
make[2]: *** [bin/supertuxkart] Error 1
CMakeFiles/Makefile2:75: recipe for target 'CMakeFiles/supertuxkart.dir/all' failed

My snapcraft project is at https://github.com/diddledan/supertuxkart-snap for anyone who wishes to fiddle :-)

[Harald Sitter (apachelogger)]

My problem is kind-of going away when using a build-snap with classic confinement (which causes automatic rpath injection at build-time of the build-snap). rpath injection seems to do a decent enough job at solving at least the pulse issue I've encountered.

That said perhaps the answer to the usr/local/lib is also rpaths. I imagine there isn't much that can be done other than rpathing or setting C*FLAGS with appropriate -L flags. gcc/ld would have build-time-set default paths for where libs generally go, unfortunately there is no way to force an additional "root" path into that list.