On 16.01.12 21:03:20, J Decker wrote: > On Mon, Jan 16, 2012 at 10:21 AM, John Drescher <dresche...@gmail.com> wrote: > > On Mon, Jan 16, 2012 at 1:15 PM, J Decker <d3c...@gmail.com> wrote: > >> On Mon, Jan 16, 2012 at 10:08 AM, Rolf Eike Beer <e...@sf-mail.de> wrote: > >>> J Decker wrote: > >>>> I just use > >>>> include_directories( ... ) > >>> > >>> This is right. > >>> > >>>> LINK_DIRECTORIES( ...} ) > >>> > >>> This is almost surely wrong. LINK_DIRECTORIES is only needed for very > >>> seldom > >>> special cases and only causes headache in all other cases. > >> > >> oh, what's the preferred method to specify the directory where the > >> library is then? > >> > > > > I believe the full path on the target_link_libraries. > > I think the problem with that is if built with gcc, then the full path > to the library is encoded and you can't load the library from the > library path, but only from where it was specified.
Thats not correct. Runtime loading of libraries depends on the runtime linker used, which is ld on Linux usually. And that one finds libraries by checking its ld.so.conf, the LD_LIBRARY_PATH and a possibly-existing RPATH/RUNPATH setting in the executable. On Windows the runtime-linker looks through the PATH variable, in the directory where the executable is and at a few system-places. What you might refer to is CMake's support for RPATH/RUNPATH on Linux, but this can be turned off, tuned so the path is relative to the executable and the linker simply ignores that if it cannot find a library at the specified place and falls back to the other two options. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
