Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[package] boost/1.74.0: RUNPATH not set to $ORIGIN

See original GitHub issue

Package and Environment Details

Package Name/Version: boost/1.74.0
Operating System+version: Linux Ubuntu 20.04
Compiler+version: GCC 9
Conan version: conan 1.31.4
Python version: Python 3.8.5

Conan profile

[settings]
arch=x86_64
arch_build=x86_64
os_build=Linux
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
compiler.cppstd=17

[options]
boost:shared=True

Problem

When linking against boost some so files will not be loaded if LD_LIBRARY_PATH is not set to directory of all imported libs.

ldd libboost_log.so

outputs:

        linux-vdso.so.1 (0x00007ffe57b4e000)
        libboost_filesystem.so.1.74.0 => not found
        libboost_thread.so.1.74.0 => not found
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcf9d332000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcf9d151000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcf9d136000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcf9d113000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcf9cf1f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fcf9d41e000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcf9cdd0000)

Neither objdump -x libboost_log.so |grep RPATH or objdump -x libboost_log.so |grep RUNPATH outputs anything.

Issue Analytics

State:
Created 3 years ago
Comments:7 (3 by maintainers)

Top GitHub Comments

1reaction

madebrcommented, Dec 21, 2020

The conanfile calls b2 to build boost. So there is no direct acces to gcc compile flags.

cci’s conanfile is full of hacks

https://github.com/conan-io/conan-center-index/blob/09c08293eac6e9a5b0d446461364ed1ae9f11a0b/recipes/boost/all/conanfile.py#L899-L900

Perhaps your $ORIGIN is passed as an argument and is substituted by bash to the empty string?

0reactions

theodor96commented, Apr 4, 2021

# do not even ask how this was figured out
#
'boost:extra_b2_flags': 'hardcode-dll-paths=true dll-path=\\"\\\'\\\\$ORIGIN\\\'\\"'

Hope it helps.

Top Results From Across the Web

Set the RUNPATH of installed shared libraries to "$ORIGIN"

When I build the “VTK-9.0.3”, all its shared libraries get the “RUNPATH” ... site-packages/vtkmodules/vtk*.so ” already get the runtime path "$ORIGIN/../.

Is $ORIGIN/lib a reasonable RUNPATH for libraries?

In all cases above, libraries always have their RUNPATH as $ORIGIN and NOT $ORIGIN/lib . For this reason it seems wrong to set...

Creating relocatable Linux executables by setting RPATH with ...

$ORIGIN is a special variable that indicate actual executable filename. ... So don't be surprised if an executable has RUNPATH instead of RPATH...

RPATH no longer respected for indirect dependencies

library] On Ubuntu 16.04 the RUNPATH allowed us to locate the libraries. ... bug report is not filed about a specific source package...

CMake Fundamentals Part 8 | Jeremi Mucha

As a refresher let's configure and build the projects and run the test ... The RPATH and RUNPATH entries support a special $ORIGIN...