Since commit d4d0dd0f6a (cmLinkLineComputer: Add ComputeLinkLibs
overload with backtraces, 2019-09-13, v3.16.0-rc1~87^2~4), backtraces
have been collected by `ComputeLinkLibs` by looking back through the
link implementation libraries for one matching the text of the link line
item. This is slow in projects with long link lines.
Instead, teach `cmComputeLinkDepends` and `cmComputeLinkInformation` to
carry backtrace information explicitly along with the text of each item.
Fixes: #20322
When CUDA is enabled, and a pure non-CUDA target has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled, don't actually perform
the device linking step, as it will fail. A target that has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled must also have CUDA
usage (either itself, or something it links to).
Fixes: #20182
Previously the CMake didn't compute the required set of libraries
needed to properly device link a static library when
CUDA_RESOLVE_DEVICE_SYMBOLS was enabled.
This replaces invocations of
- `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn`
- `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND`
- `cmSystemTools::IsOn` with `cmIsOn`
- `cmSystemTools::IsOff` with `cmIsOff`
This ability was lost in commit 81b4d10d8f (CUDA: More exhaustive checks
to determine when to do device linking, 2019-05-09, v3.15.0-rc1~82^2)
and needs to be restored to use imported static libraries that have CUDA
symbols.
Checks added in commit 81b4d10d8f (CUDA: More exhaustive checks to
determine when to do device linking, 2019-05-09, v3.15.0-rc1~82^2)
assumed that CUDA properties would be set only if CUDA is enabled.
We cannot do a device link step if we do not have the CUDA language
enabled. This was discovered as some projects unconditionally set CUDA
properties such as `CUDA_RESOLVE_DEVICE_SYMBOLS` even when the CUDA
language has not been enabled.
Fixes: #19432
Previously CMake used fairly naive logic to determine when to do
device linking which caused unnecessary device linking to occur
frequently. We now use a more exhaustive algorithm to determine
when we have a need for device linking.
Fixes: #19238
The filter in commit e768d96c74 (CUDA: Filter out host link flags during
device linking, 2018-10-22, v3.13.0-rc2~4^2~2^2) removes `-framework`
but not the framework name that comes after it. Revise the logic to
remove both.
Fixes: #18911
Suppress some cases in `Source/cmGeneratorExpressionNode.cxx` and
`Source/cmUVHandlePtr.h` where a few older compilers require a
user-defined default constructor (with `{}`).
Since commit v3.12.0-rc1~278^2 (CUDA: Pass more link libraries to device
linking, 2018-03-27) we consider every link library during device
linking and use `-Xnvlink` to pass those that do not end in `.a`.
However, nvlink breaks on versioned shared library names such as
`.so.1`. Work around this problem by not passing library paths that do
not end in `.a` or `.lib`. nvlink would not find device symbols in them
anyway.
Fixes: #18504
Since commit v3.12.0-rc1~278^2 (CUDA: Pass more link libraries to device
linking, 2018-03-27) we consider every link item during device linking.
However, items that start in `-` may be host-specific link flags that
nvcc will not understand during device linking. Filter such items using
a white list.
In particular, this allows `-pthread` to be used for host linking while
not polluting the device link line.
Issue: #18008
The nvcc device linker is designed so that each static library
with device symbols only needs to be listed once as it doesn't
care about link order. If you provide the same static library
multiple times it will error out. To make sure this occurs
we find the unique set of link items.
Previously we dropped non-target items from the device link line because
nvcc rejects paths to shared library files, and only with target items
do we know the kind of library. However, this also prevents projects
from linking to system-provided libraries like `cublas_device` that
contain device code.
Fix this by passing more link items to device linking. Items that are
not file paths, such as `-lfoo`, can simply be passed unconditionally.
Items that are targets known to be shared libraries can still be
skipped. Items that are paths to library files can be passed directly
if they end in `.a`. Otherwise, pass them using `-Xnvlink` to bypass
nvcc's front-end. The nvlink tool knows to ignore shared library files.
Issue: #16317
If a static library has the property CUDA_RESOLVE_DEVICE_SYMBOLS enabled
it will now perform the device link step. The normal behavior is
to delay calling device link until the static library is consumed by
a shared library or an executable.
Previously we had a two issues when building cuda executables
that required separable compilation. The first was that we didn't
propagate FLAGS causing any -arch / -gencode flags to be dropped, and
secondly generators such as ninja would use the CXX language flags
instead of CUDA when the executable was mixed language.
