On 05/29/2014 12:32 PM, Vadim Zhukov wrote: > I was not aware of such issue before that question. :) Yes, paths are > written in NEEDED entries if requested, that's what CMake does for > "external" libraries (outside project). Internal libraries are linked > by name, though, allowing to relocate the resulting software package, > if needed.
CMake does not consider whether a library is internal or external to the build tree. If a library is located in an implicit linker search path like /usr/lib then it will be linked by -l instead of a full path. This is because find_library is not arch-aware so when it finds paths like /usr/lib/libz.so then the proper library might actually be /usr/lib/$arch/libz.so so we use -lz to let the linker choose it. This is a hack that should be removed someday by improving find_library. Since the hack was created, CMake has learned to detect the actual linker search path used by the compiler front-end, so that information could be leveraged. Once find_library is fixed then CMake will link all libraries by full path. It would have to be taught to not do so for libraries that do not have the SONAME set. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
