69528fe6 Tests: Add case for RPATH exclusion of symlinks to implicit directories
f3102ca8 Merge branch 'backport-implicit-dir-symlinks' into implicit-dir-symlinks
c3fb650c cmOrderDirectories: Consider symlinks when checking implicit directories
b1a37362 cmOrderDirectories: Factor out implicit directory check
54a48c67 Xcode: Use proper buildable name for schema
f4977d05 Xcode: Select executable target for execution in schema
7202db5d Xcode: Fix schema container location calculation
59950821 Xcode: Do not autocreate schemes
6a54d28e Xcode: Use proper indentation for schemes
When checking whether a directory is "implicit" (e.g. implicit link
directory or implicit rpath directory), resolve the real path of both
sides of the comparison. Otherwise we will not recognize paths like
`/usr/lib32` as implicit when `/usr/lib` is implicit and `lib32` is
actually a symlink to `lib`. This can lead to addition of unnecessary
entries to the RPATH of a binary, for example.
Fixes: #16682
Add a new `CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable to allow use
of a custom suffix on `lib` directory names. This is a more general
option than that added by commit v3.7.0-rc1~504^2 (Teach find_library
and find_package to search lib32 paths, 2016-06-10). It allows the find
path to be more deterministic on custom setups.
See discussion in #10287 and #15994.
The `FIND_LIBRARY_USE_LIB<arch>_PATHS` global properties ask
`find_library` to look in `lib<arch>` directories automatically before
corresponding `lib` directories. However, if `lib<arch>` is just a
symlink to `lib` (or vice-versa) then we should skip adding the
`lib<arch>` path. Such symlinks typically only exist to satisfy
software that expects the `lib<arch>` path to be available.
Fixes: #16687
Previously bindexplib discarded read-only non-function symbols even in
executable/code sections, but in some specific cases they could still mark
functions.
An example is provided by nop.asm in the AuoExportDll test, which exports
a function only marked by a label. This symbol can be used from C/C++
code, but without this change it would result in an unresolved external
symbol when built as a DLL on Windows.
In commit 0bbd993f (Make CMAKE_HOST_SYSTEM_NAME available in scripting
context, 2016-12-26) we added a call to `uname` that checks for a zero
return value. However, on Solaris the `uname(2)` manual [1] says that
on success a non-negative value is returned. Fix our return code check
so that we detect the `SunOS` name correctly.
[1] https://docs.oracle.com/cd/E53394_01/html/E54765/uname-2.html
Sebastian Holtermann