Skip to content

RUNPATH VS RPATH cause packaging issues on linux

In ParaView Superbuild, fixup_bundle rely on chrpath/patchelf to edit the rpath/runpath of libraries it packages. The current logic works perfectly with rpath, even when a library do not have any rpath defined, as rpath is recursive.

However, even though the runpath logic is implemented as well in fixup_bundle, it fails when library do not have any runpath defined.

The one project I found that exhibit this behavior is rkcommon. rkcommon is dependency of ospray, and depends itself on tbb.

We have then:

│   │   │   │   ├── libvtkRenderingRayTracing-pv5.11.so.1 [rpath]
│   │   │   │   │   ├── librkcommon.so.1 [rpath]
│   │   │   │   │   │   ├── libtbb.so.12 [rpath of 6]

However, looking at librkcommon, we can see the rpath/runpath is never set during link:

[glow@gamma ~/dev/paraview/others/ParaView-5.11.0-RC2-MPI-Linux-Python3.9-x86_64/lib]$ readelf -d librkcommon.so

Dynamic section at offset 0x29c18 contains 32 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libtbb.so.12]
 0x0000000000000001 (NEEDED)             Shared library: [libtbbmalloc.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [librkcommon.so.1]
 0x000000000000000c (INIT)               0x102a0
 0x000000000000000d (FINI)               0x22b5c
 0x0000000000000019 (INIT_ARRAY)         0x229788

This is fine with rpath has it is recursive from the executable (rpath of 6 in libtree).

With runpath, libtbb is just not found (and use my system instead):

│   │   │   ├── libvtkRenderingRayTracing-pv5.11.so.1 [runpath]
│   │   │   │   ├── libospray.so.2 [runpath]
│   │   │   │   │   ├── librkcommon.so.1 [runpath]
│   │   │   │   │   │   └── libtbb.so.12 [default path]

rkcommon and tbb are just a real life example, but this will appear with any project not setting rpath/runpath. The fix in rkcommon is trivial, just set the rpath in rkcommon.cmake, but I think we may want to find a larger discussions. Indeed, when ParaView package generation environnement switch to runpath (which will happen at some point), packaging may break silently at any point as resulting package may even work by using system libraries.

I see a few possible solution to this:

  1. Force the use of rpath superbuild-wide. This may be the simpler fix but could be considered temporary

  2. Add a runpath when it is not set at all. That would be nice but my understanding is that it is not possible

  3. Add a superbuild-wide settings to make sure a runpath "padding" is added to all libs. This could work, however fixup_bundle in its current form do not seem to work as expected in that case.

  4. Add an error in fixup_bundle to detect that case. Since the bundling phase is able to install all libs, finxup_bundle should be able to detect that some libs that should be available are not found in the (missing) runpath.

Here is a link to a runpath ParaView package that shows the issue, if that helps: https://drive.google.com/file/d/1tR9tJUdkTUZh7LwEosELiRQy-EQETpPh/view?usp=sharing

May or may not be related to #121 (closed)

Edited by Mathieu Westphal (Kitware)