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

Clinton Stimpson clinton at elemtech.com
Sat Aug 25 12:37:42 EDT 2012


This doesn't look like a cmake bug to me.

Someone tried to "fix" dlopen() for this case you are demonstrating, when the --enable-new-dtags linker flag is used.
http://sources.redhat.com/ml/libc-hacker/2002-10/msg00048.html

But the patch was rejected because it was by design.
http://sourceware.org/ml/libc-hacker/2002-11/msg00011.html

If you add the --disable-new-dtags linker flag to your executables, they will both work.

I would suggest using absolute paths to libraries you want to dlopen().
If you need help getting a path, you can use dladdr() to get the path of your executable.  You can also put that code into a .so and it would give you a path to your .so in case it was different than your executable.

Clint

On Aug 25, 2012, at 9:52 AM, Martin Vogt wrote:

> 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.
> 
> 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]$
> 
> If this is a bug, I can open a bug report for this.
> 
> regards,
> 
> Martin
> <rpath_not_set_in_first_lib.tgz>--
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake



More information about the CMake mailing list