[CMake] Why does CMake use relative linking when I replace a shared object?

[Michael Hertling]

On 11/25/2011 08:42 PM, Mathias Gaunard wrote:
> On 11/25/2011 07:19 PM, Michael Hertling wrote:
> 
>> That's caused by the absence of an SONAME in your baz/libtest.so. If
>> there's no DT_SONAME tag in a shared library you are linking against,
>> the linker will write a DT_NEEDED tag to the resulting binary which
>> points to the library as it has been specified in the linker command
>> line, i.e. ../baz/libtest.so in your case; examine with "readelf -d".
>> Then, of course, libtest.so can be found only if the search starts in
>> the appropriate directories, e.g. in bar since it's a sibling of baz:
>> "cd bar&&  ./foo" works. If there is an DT_SONAME tag in the library,
>> the linker uses this to set the DT_NEEDED tag in the resulting binary,
>> and CMake places an SONAME in each shared library by default, even if
>> the VERSION/SOVERSION property isn't specified. See [1] for a related
>> discussion. If you really want to create a shared library by yourself,
>> do it right, e.g. with
> 
> Thank you very much for the information.
> I had no idea shared objects had that kind of behaviour.
> 
> 
>> and note that PRE_BUILD is actually PRE_LINK for Makefiles,
> 
> I know, just using PRE_BUILD because it looks better when compared to 
> POST_BUILD.
> 
> 
>> LIBRARY_OUTPUT_PATH has been obsolete for a long time, and
>> the LINK_DIRECTORIES() command means asking for trouble.
> 
> I was wondering if those variables could be affecting the base directory 
> used in the RPATH or other so-related things.

They do, but for DT_NEEDED tags containing a "/", the runtime linker
ignores rpath settings - i.e. the DT_RPATH tags generated by -rpath
options when the binary has been created. Therefore, the DT_NEEDED
tag "../baz/libtest.so" is used immediately without referring to
any DT_RPATH tags incorporated in the same binary.

>> [1] http://www.mail-archive.com/cmake-wChDC6UyXvPYtjvyW6yDsg@public.gmane.org/msg33482.html
> 
> Doesn't seem to work :(

Strange, the ML archives have it right. One more try:

<http://www.mail-archive.com/cmake@cmake.org/msg33482.html>

Regards,

Michael