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

[Christopher Harvey]

Eric Noulard wrote:
> 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
>
>
>   
Glad I called it /possible/ bug report. I ran ldd on the exec within the 
build tree. Thanks for clearing this up.