Modern distributions of packages built with MinGW tools provide `.dll.a`
import libraries. Prefer those instead of finding plain `.dll` files.
This avoids accidentally finding unrelated Windows `.dll` files.
Fixes: #20019
Add a `JOB_POOL_PRECOMPILE_HEADER` target property to specify the pool
name, and its associated `CMAKE_JOB_POOL_PRECOMPILE_HEADER` variable.
Fixes: #20217
fcde42751a FindPython: ensure new Xcode framework for Python3 is detected
dd7b741b81 macOS: Add support for new Xcode 11 frameworks directory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4198
Extend the logic from commit abe8a623d9 (GNUtoMS: Add search path for VS
2017 environment scripts, 2017-05-19, v3.8.2~1^2) to consider VS 2019
paths too.
Fixes: #20162
This moves the definition of the import library flags for Windows into a
platform specific file (much like the Darwin `-sdk` flag). This is in
preparation for re-use of the flag to make the flags handling for
executables more precise.
a9b41195d2 Handle multi-arch sysroots on Apple platforms
372c89ea38 Refactor -arch and -isysroot code usage
7a44e16d7f Refactor SDK name to path into a function
777d364913 Use xcrun instead of xcodebuild for resolving SDK path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4125
Starting with CUDA 10.2 the nvcc compiler has gained support
to automatically forward unknown flags to the host compiler.
This behavior is highly desired as projcts that mix CUDA, C, C++
run into situation where flags such as `-pthread` which aren't
supported by nvcc, are being applied to all source files and
therefore break CUDA compilation.
2d0100fac7 replace remove and remove_directory with rm in tests
5239fc5c75 cmake -E: Add rm with improved semantics over remove and remove_directory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3949
7b2dd9dedc Refactor: Use added message types in various modules
949a1e120a message: New message types to mark checks performed by CMake
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3689
Pass the value to the Swift compiler driver via `-sdk`. We already do
this for C/C++ via `-isysroot`.
This fixes command-line builds on macOS 10.15 with Xcode 11 Swift tools.
Fixes: #19880
The CMake support for Android assumes cross-compilation using the NDK,
so stub out that Android NDK support and use the Linux support that's
already invoked. Set CMAKE_HOST_SYSTEM_NAME to "Android", rather than
"Linux".
Issue: #19840
The same is done for the C and CXX language. This initializes
compiler flags like the sysroot path or deployment target.
Closes: #19794
Suggested-by: Kyle Fleming
The same is done for the C and CXX language. This initializes
compiler flags like the sysroot path or deployment target.
Closes: #19794
Suggested-by: Kyle Fleming
Add entries in Modules and Modules/Platform to support
Objective-C++ compiler determination and identification.
Add Modules to check Objective-C++ compiler flags, source
compilations, program checks, etc...
Use OBJCXX as the designator of the language, eg:
project(foo OBJCXX)
Add various tests for Objective-C++ language features. Add
tests to preserve C++ handling of .M and .mm files when
Objective-C++ is not a configured language.
Co-authored-by: Cristian Adam <cristian.adam@gmail.com>
Add entries in Modules and Modules/Platform to support
Objective-C compiler determination and identification.
Add Modules to check Objective-C compiler flags, source
compilations, program checks, etc...
Use OBJC as the designator of the language, eg:
project(foo OBJC)
Add various tests for Objective-C language features. Add
tests to preserve C++ handling of .m and .mm files when
OBJC is not a configured language.
Co-Authored-By: Cristian Adam <cristian.adam@gmail.com>
dca9c33abc Tests: Remove old IPO test
c856d4556b bindexplib: supporting llvm bitcode formats using llvm-nm
079b8e2916 Clang: prefer lld-link over link.exe
6e3655db2c Clang: add LTO support for GNU-command line clang on windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3527
This change modifies how CMAKE_RC_COMPILER is configured to improve
the out-of-box experience for developers using Clang on Windows.
The previous behavior was to require the user to explicitly specify
the resource compiler when CMake was called. The new behavior
is to automatically attempt to locate the MSVC rc binary and use that
if it's found. If rc is not available, CMake will now fall back to
Clang's llvm-rc binary.
With this change in place, trivial C/C++ programs can be generated
with Ninja and Clang on Windows without running into errors about
a missing resource compiler.
Fixes: #19318
In commit fb3370b6a1 (MSVC: Add abstraction for runtime library
selection, 2019-04-10, v3.15.0-rc1~229^2) we overlooked updating flags
for Flang on Windows. Add them now and update the MSVCRuntimeLibrary
Fortran test to work with Flang. Base the flags on those we already
use for the GNU-like Clang targeting the MSVC ABI.
Fixes: #19583
The `CMAKE_LINK_LIBRARY_FILE_FLAG` variable is meant for linkers that
want library file paths to be preceded by a flag. This is used only
for OpenWatcom to add the `library` argument before library file paths.
Refactor the approach to treat `CMAKE_LINK_LIBRARY_FILE_FLAG` as a
command-line string fragment to add just before the library file path.
This has two advantages:
* `CMAKE_LINK_LIBRARY_FILE_FLAG` now works like `CMAKE_LINK_LIBRARY_FLAG`.
* `CMAKE_LINK_LIBRARY_FILE_FLAG` can now be an attached flag whose value
is the library file path.
Technically this is a change in behavior, but this setting was created
for internal use and should be rarely used outside of CMake itself.
Fixes: #19541
The NDK build system now uses only a single toolchain in
<ndk>/toolchains/llvm/prebuilt/<host>
Its compilers are always `bin/{clang,clang++}` and its binutils are
always `bin/<triple>-*`. It is a standalone toolchain:
* The Anrdoid API level is specified at the end of `--target=`.
* The standard library may be specified via `-stdlib=`.
* No need to pass system includes or libraries explicitly.
* No need to pass `--sysroot` or `-gcc-toolchain`.
Teach CMake to recognize NDK versions that have a unified
toolchain with its own sysroot and use the above approach.
Fixes: #18739
We've long created shared objects on AIX using the linker's `-G` option
(also offered by the XL front-end). The `-G` option implies `-brtl` and
enables runtime linking. This has been largely unnecessary because we
provide all dependencies on the link line and both XL and GNU compilers
offer builtin behavior to export symbols. Since commit 0f150b69d3 (AIX:
Explicitly compute shared object exports for both XL and GNU,
2019-07-11) we compute exports explicitly and consistently.
Therefore runtime linking is no longer necessary for shared objects.
We've also long created executables on AIX using the linker's `-brtl`
option to enable runtime linking in case they load plugins at runtime.
Since commit 9f5c2040bf (AIX: Explicitly compute executable exports for
both XL and GNU, 2019-07-12) and commit 2fa920c0cd (AIX: Create import
library for executables with exports, 2019-07-16) we now provide the
linker enough information to fully resolve symbols in plugins up front.
Therefore runtime linking is no longer necessary for executables.
Drop use of `-G` for creating shared objects and use the XL `-qmkshrobj`
and GCC `-shared` options instead. Both invoke the linker with the
`-bM:SRE -bnoentry` options to create a shared object without runtime
linking enabled. Also drop use of `-brtl` for creating executables.
Issue: #19163
On AIX, plugins meant to be loaded into executables via `dlopen` must be
linked with access to a list of symbols exported from the executable in
order to use them (when not using runtime linking). The AIX linker
supports specifying this list as an "import file" passed on the command
line either via the `-bI:...` option or (with a leading `#! .` line) as
a normal input file like any other library file.
The linker import file plays the same role on AIX as import libraries do
on Windows. Teach CMake to enable its import library abstraction on AIX
for executables with the `ENABLE_EXPORTS` target property set. Teach
our internal `ExportImportList` script to optionally generate a leading
`#! .` line at the top of the generated export/import list. Update our
rule for linking an executable with exports to generate a public-facing
"import library" implemented as an AIX linker import file.
With this approach, our existing infrastructure for handling import
libraries on Windows will now work for AIX linker import files too:
* Plugins that link to their executable's symbols will be automatically
linked using the import file on the command line.
* The executable's import file will be (optionally) installed and
exported for use in linking externally-built plugins.
This will allow executables and their plugins to build even if we later
turn off runtime linking.
Issue: #19163
On AIX, symbols in executables must be exported in order to be visible
to modules (plugins) they load via `dlopen`. Prior to policy `CMP0065`,
CMake linked all executables with flags to export symbols, but the NEW
behavior for that policy is to do so only for executables that have the
`ENABLE_EXPORTS` target property set. In both cases, CMake has always
used the AIX linker option `-bexpall` option to export symbols from
executables.
This has worked fairly well with the XL compiler, but with the GNU
compiler it works only for C ABI symbols. The reason is that `-bexpall`
does not export symbols starting in `_` but the GNU C++ ABI mangles all
symbols with a leading `_`. Therefore we have only supported C ABI
plugins with the GNU compiler on AIX. Some projects have tried to work
around this by replacing `-bexpall` with `-bexpfull`, but the latter
often exports symbols that we do not want exported.
Avoid using `-bexpall` for executables by instead using by our own
internal `ExportImportList` script to compute symbol export lists from
the object files to be linked into an executable. Pass the explicitly
computed export list to the AIX linker's `-bE:...` option. We already
do this for shared object exports.
Issue: #19163
On AIX, symbols in shared objects must be exported in order to be
visible to dependents (similar to Windows). The AIX linker provides a
`-bE:...` option to specify a file listing symbols to be exported.
Compilers offer some features to help:
* When the XL compiler is invoked with its `-qmkshrobj`/`-G` options for
creating shared objects (without/with runtime linking), it recognizes
when no explicit `-bE:...` linker option is specified and runs a
`CreateExportList` tool provided with the compiler to compute one from
the object files. Since commit d468a2c2cb (XL: Avoid copying archives
into shared libraries that link them, 2011-04-07, v2.8.5~153^2) CMake
runs `CreateExportList` explicitly to ensure it only looks at the object
files and not any library files.
* When the GNU compiler is invoked with its `-shared` option for creating
shared objects, its internal `collect2` tool recognizes when no explicit
`-bE:...` linker option is specified and computes one itself from the
object files. However, it sometimes includes extra symbols such as
`.__init_aix_libgcc_cxa_atexit`.
Introduce our own internal `ExportImportList` script to compute symbol
export lists from object files. Use a basic implementation for now: it
can be extended as needed later. Update our shared library creation
rules to run the script explicitly for both the XL and GNU compilers.
Issue: #19163
We removed `-brtl` in commit bce7a2a3a5 (AIX: Do not use -brtl to create
shared libraries, 2013-03-11, v2.8.11~103^2~1) but it was added again by
commit f254276fc1 (AIX,HP-UX: Fix RPATH handling when CMP0065 is set to
NEW, 2015-12-11, v3.4.2~4^2). Since the latter commit we initialize the
`CMAKE_{SHARED,MODULE}_LINKER_FLAGS` to use the `-brtl` linker flag.
This is unnecessary because we already use the `-G` linker flag which
implies `-brtl`.
The latter commit also moved `-brtl` to `CMAKE_EXE_LINKER_FLAGS` from
flags that were always included in executable link lines with CMP0065
OLD behavior and are not part of the change intended by CMP0065. Leave
this for now as we've always enabled runtime linking for executables
(and implicitly done so via -G for shared libraries and modules).
Issue: #13997
Issue: #19163
