[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