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

[Christopher Harvey]

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.

Thanks,
Chris.