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

[Mathias Gaunard]

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.


> [1] http://www.mail-archive.com/cmake-wChDC6UyXvPYtjvyW6yDsg@public.gmane.org/msg33482.html

Doesn't seem to work :(