[CMake] RPATH not set for "first" build library

Eric Noulard eric.noulard at gmail.com
Sat Aug 25 13:03:07 EDT 2012


2012/8/25 Martin Vogt <mvogt1 at gmail.com>:
> Hello,
>
> I have a library "A", which dlopens another library "B".
>
> But this does not work with cmake under the following circumstances:
>
> - in tree build
> - library in another directory
>
> I have attached an example for the behaviour.
>
> The reason for this is, that cmake does not set the RPATH in library A,
> and thus dlopen does not work on library B:
>
> library A:
>
>>readelf -d build/libmyopen.so
>>[..]
>> 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
>> 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>> 0x000000000000000e (SONAME)             Library soname: [libmyopen.so]
>> 0x000000000000000c (INIT)               0x648
>
> The working version is a library A1
>
>>readelf -d build/libmyopen1.so
>> 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>> 0x000000000000000e (SONAME)             Library soname: [libmyopen1.so]
>> 0x000000000000000f (RPATH)              Library rpath: [/tmp/rpath_not_set_in_first_lib/build]
>> 0x000000000000001d (RUNPATH)            Library runpath: [/tmp/rpath_not_set_in_first_lib/build]
>> 0x000000000000000c (INIT)               0x678
>
> The only difference between library A and library A1 is that
> A1 is the "second" library in the cmake projekt.
> Whereas "second"means, that A1 is linked against an arbitatry
> other library in the project.

Precisely, rpath is set in the build tree for "myopen1" because you wrote:
target_link_libraries(myopen1 myopen dl)

whereas for "myopen" you wrote:
target_link_libraries(myopen dl)

so this is the default CMake behavior when one library is linked to
any other library in the same project
http://www.cmake.org/Wiki/CMake_RPATH_handling
"By default if you don't change any RPATH related settings, CMake will
link the executables and shared libraries with full RPATH to all used
libraries in the build tree"

This information can be found here.
cmake --help-variable CMAKE_SKIP_BUILD_RPATH

if you set CMAKE_SKIP_BUILD_RPATH you won't have any RPATH set in the
build tree.
In any you won't get any build RPATH set for "myopen" since
target_link_libraries(myopen dl)

does not require any.

> This is from the demo project in the attachment:
>
> [/tmp/rpath_not_set_in_first_lib]$./build/works
> dlopen start
> [/tmp/rpath_not_set_in_first_lib]$./build/works_not
> dlopen start
> libdummy.so: cannot open shared object file: No such file or directory
> [/tmp/rpath_not_set_in_first_lib]$

Both executable works fine on my box (Debian Wheezy + CMake 2.8.9).
Did you try to
$ readelf -d works
and
$ readelf -d works_not
in my case both have:
0x000000000000000f (RPATH)              Library rpath:
[/home/erk/.../rpath_not_set_in_first_lib/build

Now independently from RPATH setting of your library, it doesn't seems
wise to rely on RPATH setting of a library for dlopen-ing some other library?

dlopen has rules for looking up for library
"If filename contains a slash ("/"), then it is  interpreted  as  a
(relative  or
 absolute) pathname.  Otherwise, the dynamic linker searches for the library
  as follows (see ld.so(8) for   further details):"
....

You should choose the way to use dlopen you want to support in your lib.
I think CMake is out-of-the-loop for this, since it cannot "guess" the
relationship
between the dlopened "libdummy.so" library from the CMakeLists.txt....

The fact that libdummy.so is in the rpath of one of the library the executable
is linked against is just a coincidence or did I miss something?
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org


More information about the CMake mailing list