| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
In commit 88c740462c (CUDA/Clang: Add support for MSVC ABI on Windows
using GNU-like frontend, 2024-01-17) we updated the message for the
existing check to mention CUDA, but neglected to update the check
itself.
Issue: #25648
|
|\
| |
| |
| |
| |
| |
| |
| | |
88c740462c CUDA/Clang: Add support for MSVC ABI on Windows using GNU-like frontend
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Merge-request: !9172
|
| |
| |
| |
| | |
Fixes: #20776
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When targeting the GNU ABI, we consider `.a` libraries first but also
accept `.lib`. For symmetry, when targeting the MSVC ABI, we now
consider `.lib` first but also accept `.a`.
This adds support for meson-generated static libraries, which are named
with the pattern `lib${foo}.a`:
* https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa
Note that this was previously attempted by
* commit be848a71b0 (MSVC: Teach find_library to consider the 'libfoo.a'
naming convention, 2022-09-19, v3.25.0-rc1~111^2)
but was reverted by
* commit 955d6245c1 (MSVC: Revert "Teach find_library to consider the
'libfoo.a' naming convention", 2022-11-28, v3.25.1~6^2)
due to problems finding GNU ABI libraries in PATH-derived prefixes.
Since then,
* commit 0a81110b84 (find_(library|file|path): Drop PATH-derived search
prefixes, 2023-09-14, v3.28.0-rc1~91^2)
removed the problematic search paths, so we can restore this change.
Fixes: #23975
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
df025444b2 LinkerId: Identify AIX and SunOS system linkers
c1e48a19a5 LinkerId: Try multiple flags to detect linker id and version
1e42a0cf18 LinkerId: Match linker id and version more robustly
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9057
|
| |
| |
| |
| | |
Populate `CMAKE_<LANG>_COMPILER_LINKER_{ID,VERSION}` on these platforms.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
0502b345f2 LLVMFlang Fortran: enhance link capabilities
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9025
|
| |/
| |
| |
| |
| | |
* Add support for "LINKER:" prefix.
* Add support, on Linux, for linker selection through CMAKE_LINKER_TYPE variable.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
f20c5c6f20 MSVC: Teach find_library to consider Rust's '${name}.dll.lib' convention
7598ea5389 Tests: Add case covering find_library behavior when targeting MSVC ABI
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9046
|
| |
| |
| |
| |
| |
| |
| | |
This convention is used by Rust toolchains (rustc/cargo/cargo-c) for the
MSVC ABI.
Fixes: #25478
|
|/
|
|
|
|
|
|
|
| |
LLVMFlang 18.0 adds MSVC runtime library selection flags and associated
Fortran runtime library variants. Resolve the corresponding FIXME left
by commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
|
|\
| |
| |
| |
| |
| |
| | |
ef49ed0fe1 LLVMFlang: Fix MSVC ABI debug information format options
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9037
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2) we incorrectly recorded `-g` as
supporting the `ProgramDatabase` format, but it is actually `Embedded`,
matching Clang.
In order to support easy integration with C and C++ projects that use
the `.pdb` debug formats, pretend LLVMFlang supports them and just don't
actually emit any debug information.
Issue: #24840
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a behavior change. You can still set ADSP_ROOT/CMAKE_ADSP_ROOT
to hint the find_program() invocations for the CCES binaries, but it is
no longer necessary if they are already in PATH.
The reason is: CMAKE_ADSP_ROOT is only used to find the binaries. If
they are in PATH, there is no need to supply the root path. If they are
not in PATH, you can hint still hint it as before.
The other option would be to use find_path() to get CMAKE_ADSP_ROOT from
the path to one of the bins, but that would be convoluted and pointless.
There are some circumstances where the binaries are available, but the
ADSP install is not. For example, from my own dev environment:
https://github.com/joshchngs/macos-sharc-tools
Here, the `cc21k` et. al. binaries are actually shell scripts which
launch the real binary inside a running VM.
|
| |
| |
| |
| | |
This is the default install location on Linux.
|
| |
| |
| |
| |
| |
| | |
This still uses CMAKE_ADSP_ROOT as the PATHS argument, so the same
behavior should be retained - but now the Platform will work without
needing to supply the root, if the binaries are already in $PATH.
|
| |
| |
| |
| | |
The binaries are obviously not .exe-suffixed on Linux
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some platforms, Apple or Windows for instance, do not require to duplicate
static libraries to resolve mutual dependencies. Moreover, Xcode version 15
emits a warning if a library is duplicated.
On Windows, enable a better control of libraries order.
Fixes: #20722, #25297
|
| |
| |
| |
| |
| |
| |
| |
| | |
Some declarations were inconsistent.
For example, "LINKER:-force_load <LIBRARY>" was translated to
"-Xlinker -force_load /path/to/library". The correct translation
should be "-Xlinker -force_load -Xlinker /path/to/library" because
the library is an argument to the -force_load option.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extract the effective linker during the computation of implicit artifacts
delivered by the compiler to the linker.
Define various variables describing the linker:
* CMAKE_<LANG>_COMPILER_LINKER
* CMAKE_<LANG>_COMPILER_LINKER_VERSION
* CMAKE_<LANG>_COMPILER_LINKER_ID
* CMAKE_<LANG>_COMPILER_LINKER_FRONTEND_VARIANT
This is complementary to feature introduced by commit 96a953b1ed
(Add options to specify linker tool, 2023-09-27).
Fixes: #17596, #18209, #25344
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
|
|
|
|
|
|
|
|
|
|
| |
The compiler does not yet support everything needed to integrate well
with the MSVC ABI, in particular for runtime library selection and debug
format selection. Document them in FIXME comments and leave this
support undocumented by CMake for now.
Fixes: #24840
Inspired-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
|
|
|
|
|
|
|
| |
Add compiler information modules. Update the test suite.
Fixes: #25032
Co-authored-by: Brad King <brad.king@kitware.com>
|
|
|
|
| |
Use the compiler option rather than the linker one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSYS2 and similar MinGW/MSYS distributions define development
environments with a `MSYSTEM` environment variable. Each such
environment has a documented installation prefix for its packages,
often provided by a `MSYSTEM_PREFIX` environment variable.
Since commit 84a25fc263 (cmake_host_system_information: Add
MSYSTEM_PREFIX query, 2023-09-08) we can look up this prefix.
Add `$MSYSTEM_PREFIX/local` and `$MSYSTEM_PREFIX` to our system search
prefixes when targeting MinGW under `MSYSTEM` environments. This is
their equivalent to `/usr/local` and `/usr`, which we search by default
on UNIX systems.
Issue: #24216
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
bfe4722a61 Android: Restore platform info and search paths shared with Linux
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8626
|
| |
| |
| |
| |
| |
| |
| |
| | |
These were accidentally dropped by commit 1373373823 (enable_language:
Establish target platform identification variables earlier, 2023-06-06,
v3.27.0-rc1~3^2~1).
Fixes: #25077
|
|/ |
|
|
|
|
|
|
|
|
|
| |
Restore definition of `ANDROID` and `UNIX` when `CMAKE_SYSTEM_VERSION`
is `1`. This was broken by commit 1373373823 (enable_language:
Establish target platform identification variables earlier, 2023-06-06,
v3.27.0-rc1~3^2~1).
Fixes: #25004
|
|
|
|
|
|
|
|
| |
Set target platform identification variables like `APPLE` and `LINUX`
as soon as the target system is identified. This makes them available
during toolchain and binutils selection.
Fixes: #23333
|
|
|
|
|
|
|
|
| |
Make `CMAKE_LIBRARY_ARCHITECTURE_REGEX` available while determining
compilers before `Platform/{kFreeBSD,GNU}` is loaded.
Follow up commit cc737ae829 (Linux: Provide multiarch library directory
regex earlier, 2023-05-31).
|
|
|
|
|
| |
Recent AppleClang compilers identify themselves as
`Apple clang version 14.0.3 (clang-1403.0.22.14.1)`.
|
|
|
|
|
| |
Make `CMAKE_LIBRARY_ARCHITECTURE_REGEX` available while determining
compilers before `Platform/Linux` is loaded.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 79921fb00c (IntelLLVM: Set linker to compiler driver for
Windows, 2021-10-19, v3.23.0-rc1~127^2) we default to the compiler
driver as linker for executables, shared libraries, and static
libraries. Not doing so for shared modules was an oversight. Copying
the shared library command line for shared modules fixes the problem
(and also is what we do for MSVC).
The MSVC linker is fine for many cases, however it does not support GPU
offload code generated by the IntelLLVM compilers. Using the compiler
driver as linker, or at least a linker that understands the object
format, is required for linking shared modules that use GPU offload
(e.g., with SYCL or OpenMP).
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
|
|
|
|
| |
Closes: #24839
|
| |
|
|
|
|
|
|
|
| |
Visual Studio always uses a complete NDK and not a standalone toolchain.
Let CMake handle the NDK and related logic correctly, avoid trying to
find the standalone toolchain version from the unified clang toolchain
in newer NDKs.
|
|
|
|
|
|
| |
Visual Studio 17 (Marketing name: Visual Studio 2022) still ships with
"3.0" as most recent Variant of the Android application type.
Use this revision.
|
|
|
|
| |
Fixes: #24123
|
|\
| |
| |
| |
| |
| |
| | |
9693191582 Swift: Emit debug information on Windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8090
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When building on Windows, pass `-debug` to the linker to emit the PDB
(or `-debug:dwarf` when building with lld and using DWARF). We would
previously not do this which meant that we never emitted the debug
information making debugging more difficult.
Fixes: #24423
|
| |
| |
| |
| |
| |
| | |
LCC < 1.24 has no way to disable integrated Fortran preprocessor,
and it can't produce preprocessed files explicitly. So we
disable all functionality (and therefore tests) related to it.
|
|/
|
|
|
| |
There wasn't a liblfortran library before 1.24 (actually 1.24.01),
and it is replaced by libgfortran in 1.26.03 and later.
|
|\
| |
| |
| |
| |
| |
| | |
cb0b9452e8 Android: Provide CMAKE_ANDROID_NDK_VERSION with NDK legacy toolchain file
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8170
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This variable has been provided since commit 746906242d (Android: Detect
NDK version number, 2021-02-26, v3.20.0-rc3~1^2~3) when using CMake's
NDK support or the modern NDK toolchain file. Since commit 005e2cdfb0
(Android: Do not use gold for ndk >= r22, 2021-02-26, v3.20.0-rc3~1^2)
we need the value in our compiler/platform information files, so provide
it when using the NDK legacy toolchain file too.
Revert commit 1c86e397fe (Android/Clang: Tolerate undefined
CMAKE_ANDROID_NDK_VERSION, 2022-09-16, v3.25.0-rc1~118^2) since the
variable should now always be defined.
Issue: #21772
Fixes: #24386
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
19509249a5 Android: Revert setting LINUX variable on Android target systems
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Nevala <robert.nevala@king.com>
Acked-by: n00b42 <github.com@mail.msdigital.de>
Merge-request: !7963
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
955d6245c1 MSVC: Revert "Teach find_library to consider the 'libfoo.a' naming convention"
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7962
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
b47092fddb MinGW: Fix regression when windres is not found
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7964
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This add correct Open Watcom support for 16-bit Windows 3.x.
It replace existing strange mixture with WIN32 stuff which implement 16-bit Windows target partially as part of WIN32 stuff.
Now pre-defined OS ID Windows3x is used instead of confusing WIN32.
It support properly 16-bit and 32-bit application for 16-bit Windows host.
32-bit applications are build with OW WIN386 extender.
It is used similar as for other platforms by set CMAKE_SYSTEM_NAME=Windows3x and CMAKE_SYSTEM_PROCESSOR=I86 for 16-bit application or CMAKE_SYSTEM_PROCESSOR=x86 for 32-bit WIN386 extender application running on 16-bit Windows 3.x.
CMAKE_SYSTEM_NAME=Windows is used only for WIN32 applications.
|