OpenBSD shared library names end in a ".#.#" version number suffix.
Teach cmComputeLinkInformation to tolerate the extra suffix after
the normal library name suffixes when parsing library names.
The default OS X 10.4 linker incorrectly searches for dependencies of
linked shared libraries only under the -isysroot location. It fails to
find dependencies of linked shared libraries in cases such as the
ExportImport test. It produces errors like:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
libtestLib3Imp.dylib
referenced from: /.../ExportImport/Root/lib/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _testLib3Imp
referenced from libtestLib3lib expected to be defined in
libtestLib3Imp.dylib
or with CMAKE_SKIP_RPATH off to enable install_name in the Export side:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
/Developer/SDKs/MacOSX10.4u.sdk/.../ExportImport/Export/impl/libtestLib3Imp.dylib
referenced from: /.../ExportImport/Export/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:_testLib3Imp
referenced from libtestLib3lib expected to be defined in
/.../ExportImport/Export/impl/libtestLib3Imp.dylib
Note how "/Developer/SDKs/MacOSX10.4u.sdk" is prepended to the dependent
library path.
Commit 2cff26fa (Support linking to shared libs with dependent libs,
2008-01-31) and commit 82fcaebe (Pass dependent library search path to
linker on some platforms, 2008-02-01) worked around the problem by
defining platform variable CMAKE_LINK_DEPENDENT_LIBRARY_FILES. It tells
CMake to link to dependent libraries explicitly by their path thus
telling the linker where to find them.
Unfortunately the workaround had the side effect of linking dependent
libraries and defeats most benefits of LINK_INTERFACE_LIBRARIES.
Fortunately OS X 10.5 and above do not need to find transitive
dependencies at all so we can avoid the workaround on Modern OS X.
Teach cmComputeLinkInformation to generate the "-framework" option as a
separate link item preceding the actual framework name. Then escape the
framework name to pass as an argument through a shell. This fixes the
link line for frameworks with spaces in the name.
The build system generators that call cli.GetItems() and generate the
final list of items on the link line already handle escaping correctly
for items that are paths. However, for raw link items like "-lfoo" they
just pass through to the command line verbatim. This is incorrect. The
generators should escape these items too. Unfortunately we cannot fix
that without introducing a new CMake Policy because projects may already
be passing raw link flags with their own escapes to work around this
bug. Therefore we punt on this bug for now and go with the above fix.
Commit afd7d4ca (Add target property LINK_SEARCH_END_STATIC, 2008-01-31)
defined a property to ensure that static runtime libraries get selected.
Add a property to specify that all libraries whose type is unknown, such
as "-lm", should be assumed static. Furthermore it assumes that an
option such as "-static" is also used so that no initial -Bstatic is
needed.
In cmComputeLinkInformation we match library names with a regular
expression, possibly extracting the 'lib' prefix. The regex component
to match the prefix always allows an empty prefix to be matched, as in
"(lib|)". Avoid every adding an empty prefix option earlier in the
regex, as in "(|lib|)", because it will be preferred and 'lib' will
never match.
Detect the runtime linker's search path and add to the compile time
linker's search path. This is needed because OpenBSD's static linker
does not search for shared library dependencies in the same places as
the runtime linker.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
In cmComputeLinkInformation::Compute we add implicit link information
from languages other than the linker language to the end of the link
line. This factors out that code into separate methods to improve
readability and organization.
We list implicit link items of languages linked into a target but filter
them by the implicit libraries known to be passed by the main linker
language. Implicit link flags like "-z..." should not be filtered out
because they are not libraries.
In cmComputeLinkInformation we recognize link options that look like
library file names, but pass flags starting in '-' through untouched.
This fixes the ordering of the check to recognize '-' flags first in
case the rest of the option looks like a library file name, as in the
case of "-l:libfoo.a".
In cmComputeLinkInformation we construct regular expressions to
recognize library file names. This fixes the expressions to not allow a
colon (':') in the file name so that "-l:libfoo.a" is left alone.
This adds implicit libraries and search directories for languages linked
into a target other than the linker language to its link line. For
example, when linking an executable containing both C++ and Fortran code
the C++ linker is used but we need to add the Fortran libraries.
The variables
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
contain the implicit libraries and directories for each language.
Entries for the linker language are known to be implicit in the
generated link line. Entries for other languages that do not appear in
the known implicit set are listed explicitly at the end of the link
line.
This passes the build configuration to most GetLinkerLanguage calls. In
the future the linker language will account for targets linked in each
configuration.
This method previously required the global generator to be passed, but
that was left from before cmTarget had its Makefile member. Now the
global generator can be retrieved automatically, so we can drop the
method argument.
The fix for issue #9130 appends ':' to the end of the build-tree RPATH
unconditionally. This changes the fix to add ':' only when the RPATH is
not empty so that we do not create a build-tree RPATH with just ':'. An
empty RPATH produces no string at all, so there is no chance of merging
with a symbol name anyway.
In ELF binaries the .dynstr string table is used both for the RPATH
string and for program symbols. If a symbol name happens to match the
end of the build-tree RPATH string the linker is allowed to merge the
symbols.
We must not allow this when the RPATH string will be replaced during
installation because it will mangle the symbol. Therefore we always pad
the end of the build-tree RPATH with ':' if it will be replaced. Tools
tend not to use ':' at the end of symbol names, so it is unlikely to
conflict. See issue #9130.
HP-UX uses both .sl and .so as extensions for shared libraries. This
teaches CMake to recognize .so shared libraries so they are treated
properly during link dependency analysis.
In cmComputeLinkInformation items in the final link line returned by
GetItems now contain a pointer to their corresponding cmTarget if they
were produced by a target. This makes available the set of all targets
linked.
When creating an IMPORTED target for a library that has been found on
disk, it may not be known whether the library is STATIC or SHARED.
However, the library may still be linked using the file found from disk.
Use of an IMPORTED target is still important to allow per-configuration
files to be specified for the library.
This change creates an UNKNOWN type for IMPORTED library targets. The
IMPORTED_LOCATION property (and its per-config equivalents) specifies
the location of the library. CMake makes no assumptions about the
library that cannot be inferred from the file on disk. This will help
projects and find-modules import targets found on disk or specified by
the user.
In CMake 2.4 the generated link line for a target always preserved the
originally specified libraries in their original order. Dependencies
were satisfied by inserting extra libraries into the line, though it had
some bugs. In CMake 2.6.0 we preserved only the items on the link line
that are not known to be shared libraries. This reduced excess
libraries on the link line. However, since we link to system libraries
(such as /usr/lib/libm.so) by asking the linker to search (-lm), some
linkers secretly replace the library with a static library in another
implicit search directory (developers can override this by using an
imported target to force linking by full path). When this happens the
order still matters.
To avoid this and other potential subtle issues this commit restores
preservation of all non-target items and static library targets. This
will create cases of unnecessary, duplicate shared libraries on the link
line if the user specifies them, but at least it will work. In the
future we can attempt a more advanced analysis to safely remove
duplicate shared libraries from the link line.
We never explicitly specify system library directories in linker or
runtime search paths. Furthermore, libraries in these directories are
always linked by asking the linker to search for them. We need to
generate a warning when explicitly specified search directories contain
files that may hide the system libraries during the search.
This change introduces policy CMP0008 to decide how to treat full path
libraries that do not appear to be valid library file names. Such
libraries worked by accident in the VS IDE and Xcode generators with
CMake 2.4 and below. We support them in CMake 2.6 by introducing this
policy. See policy documentation added by this change for details.
Sometimes we ask the linker to search for a library for which the path
is known but for some reason cannot be specified by full path. In these
cases do not include the library in CMP0003 warnings because we know the
extra paths are not needed for it.
- This case worked accidentally in CMake 2.4, though not in Makefiles.
- Some projects build only with the VS IDE on windows and have this
mistake.
- Support them when 2.4 compatibility is enabled by adding the extension.
- Place the built library in foo.framework/Versions/A/foo
- Do not create unused content symlinks (like PrivateHeaders)
- Do not use VERSION/SOVERSION properties for frameworks
- Make cmTarget::GetDirectory return by value
- Remove the foo.framework part from cmTarget::GetDirectory
- Correct install_name construction and conversion on install
- Fix MACOSX_PACKAGE_LOCATION under Xcode to use the
Versions/<version> directory for frameworks
- Update the Framework test to try these things
- CMake 2.4 added link directories for targets linked
in the optimized configuration even when building debug
- Old behavior for policy CMP0003 must account for this
- Give example code to avoid the warning
- Make explanation more consise
- Explicitly state this is for compatibility
- Issue the warning for at most one target
- Targets built in the tree now add compatibility paths too
- The warning message's first list includes at most one item
for each unique compatibility path
- Clarified error message further
- Policy is WARN by default so projects will build
as they did in 2.4 without user intervention
- Remove CMAKE_LINK_OLD_PATHS variable since it was
never in a release and the policy supercedes it
- Report target creation backtrace in warning message
since policy should be set by that point
- Move computation of extended build-tree rpath
to cmComputeLinkInformation
- Only enable the extended build-tree rpath if
the target will be installed
- Generalize the interface of file(CHRPATH)
- When changing the rpath on installation only
replace the part generated by CMake because
the native tools (ex SunCC on Linux) might have
added their own part to the rpath
- Add cmSystemTools::ChangeRPath method
- Add undocumented file(CHRPATH) command
- When installing use file(CHRPATH) to change the rpath
instead of relinking
- Remove CMAKE_CHRPATH lookup from CMakeFindBinUtils
- Remove CMAKE_USE_CHRPATH option since this should
always work
- Reduce false positives in cases of unknown soname
- Make library extension regular expressions match only at end of string
- When linking to libraries in implicit dirs convert to the -l option
only if the file name is one that can be found by the linker
(ex. /usr/lib/libfoo.so.1 should be linked by full path)
- Add cmSystemTools::GuessLibrarySOName to guess the soname of a
library based on presence of a symlink
- In cmComputeLinkInformation try to guess an soname before assuming
that a third-party library is built without an soname
- In cmOrderDirectories guess the soname of shared libraries in cases
it is otherwise unknown
- Use linker search path -L.. -lfoo for lib w/out soname
when platform sets CMAKE_PLATFORM_USES_PATH_WHEN_NO_SONAME
- Rename cmOrderRuntimeDirectories to cmOrderDirectories
and generalize it for both soname constraints and link
library constraints
- Use cmOrderDirectories to order -L directories based
on all needed constraints
- Avoid processing implicit link directories
- For CMAKE_OLD_LINK_PATHS add constraints from libs
producing them to produce old ordering
Brad King
Modestas Vainius
Alex Neundorf
Chuck Atkins
David Cole
Bill Hoffman