diff options
author | Brad King <brad.king@kitware.com> | 2015-04-07 14:43:47 (GMT) |
---|---|---|
committer | Brad King <brad.king@kitware.com> | 2015-04-09 15:29:18 (GMT) |
commit | 882f48e5ba335a1dbc1750c23e6dea5fa92a3adc (patch) | |
tree | 7783686bed3456d95538a4770dff27f0e24963bc /Help/command | |
parent | 318cd37097c724fac13a364fe3beb21055575ae7 (diff) | |
download | CMake-882f48e5ba335a1dbc1750c23e6dea5fa92a3adc.zip CMake-882f48e5ba335a1dbc1750c23e6dea5fa92a3adc.tar.gz CMake-882f48e5ba335a1dbc1750c23e6dea5fa92a3adc.tar.bz2 |
Link libraries by full path even in implicit directories
When CMP0003 was first introduced we wanted to link all libraries by
full path. However, some projects had problems on platforms where
find_library would find /usr/lib/libfoo.so when the project really
wanted to link to /usr/lib/<arch>/libfoo.so and had been working by
accident because pre-CMP0003 behavior used -lfoo to link.
We first tried to address that in commit v2.6.0~440 (Teach find_library
to avoid returning library paths in system directories, 2008-01-23) by
returning just "foo" for libraries in implicit link directories. This
caused problems for projects expecting find_library to always return a
full path. We ended up using the solution in commit v2.6.0~366 (...
switch library paths found in implicit link directories to use -l,
2008-01-31). However, the special case for libraries in implicit link
directories has also proven problematic and confusing.
Introduce policy CMP0060 to switch to linking all libraries by full path
even if they are in implicit link directories. Explain in the policy
documentation the factors that led to the original approach and now to
this approach.
Diffstat (limited to 'Help/command')
-rw-r--r-- | Help/command/target_link_libraries.rst | 16 |
1 files changed, 11 insertions, 5 deletions
diff --git a/Help/command/target_link_libraries.rst b/Help/command/target_link_libraries.rst index 393c8b4..d903d05 100644 --- a/Help/command/target_link_libraries.rst +++ b/Help/command/target_link_libraries.rst @@ -34,14 +34,20 @@ Each ``<item>`` may be: automatically be added in the build system to make sure the named library target is up-to-date before the ``<target>`` links. + If an imported library has the :prop_tgt:`IMPORTED_NO_SONAME` + target property set, CMake may ask the linker to search for + the library instead of using the full path + (e.g. ``/usr/lib/libfoo.so`` becomes ``-lfoo``). + * **A full path to a library file**: The generated link line will - normally preserve the full path to the file. However, there are - some cases where CMake must ask the linker to search for the library - (e.g. ``/usr/lib/libfoo.so`` becomes ``-lfoo``), such as when it - appears in a system library directory that the compiler front-end - may replace with an alternative. Either way, the buildsystem will + normally preserve the full path to the file. The buildsystem will have a dependency to re-link ``<target>`` if the library file changes. + There are some cases where CMake may ask the linker to search for + the library (e.g. ``/usr/lib/libfoo.so`` becomes ``-lfoo``), such + as when a shared library is detected to have no ``SONAME`` field. + See policy :policy:`CMP0060` for discussion of another case. + If the library file is in a Mac OSX framework, the ``Headers`` directory of the framework will also be processed as a :ref:`usage requirement <Target Usage Requirements>`. This has the same |