[CMake] possible bug report on release binary dynamic library search paths

[Eric Noulard]

2008/9/19 Christopher Harvey <chris at basementcode.com>:
> Sorry about the long subject,
>
> My question is about the way cmake defines dynamic link library search paths
> for release builds of executables. I've got an executable, written in C++
> that depends on a shared library within the same project. When I run ldd on
> that executable I get this output
> ldd test1
>   linux-gate.so.1 =>  (0xb7fab000)
>   libPortal.so => ../src/libPortal.so (0xb7f9b000)
>   libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
> (0xb7ea7000)
>   libm.so.6 => /lib/libm.so.6 (0xb7e81000)
>   libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1
> (0xb7e76000)
>   libc.so.6 => /lib/libc.so.6 (0xb7d46000)
>   /lib/ld-linux.so.2 (0xb7fac000)
>
> notice the libPortal.so path, it points to a local directory, yet libPortal
> is a release build. Why would cmake have a release build point to a local
> directory that wont exist on another users machine? Also, if the test1 exec
> was installed into /usr/bin and the .so into /usr/lib wouldn't that mean the
> exec would still point to ../src? If that's the case the src directory
> wouldn't exist. I expected cmake not to include any information on where to
> find the library and let the unix system handle that itself with environment
> variables for example. If this is acceptable behavior in a unix system,
> please let me know.

CMake will update the rpath as soon as you run
make install (or make package if you build a binary package using cpack)

Did you run ldd on an excutable installed with "make install" or inside
the build tree?

If you want to change RPATH handling behavior you should have look at:
http://www.cmake.org/Wiki/CMake_RPATH_handling


-- 
Erk