GCC mistakenly issues the pedantic warning "ISO C forbids conversion of
function pointer to object pointer type". With -pedantic-errors in the
compile flags, that diagnostic prevents check_symbol_exists() from
detecting function symbols.
The solution is to filter out -pedantic-errors (and -Werror, just to be
future proof) before invoking try_compile().
Fixes: #13208
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-strip` over `strip` when using Clang. However,
`llvm-strip` from Clang versions prior to 11 require extra flags to
strip everything. Until our `install(TARGETS)` logic learns to add
those flags, avoid using older versions of `llvm-strip` by default.
Fixes: #22785
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
Since commit 6051a49c78 (Visual Studio: Add Android support, 2020-06-12,
v3.19.0-rc1~619^2) we run MSBuild to build a sample project to detect
the sysroot. Previously we relied on `CMAKE_VS_MSBUILD_COMMAND` being
available. That required commit d5b5c19278 (cmGlobalGenerator:
FindMakeProgram() before CMakeDetermineSystem, 2020-06-15,
v3.19.0-rc1~619^2~3) to make it available early enough. However, that
ordering broke `CMAKE_GENERATOR_INSTANCE` so we need to prepare to
revert it. Use `cmake_host_system_information` to get the location of
MSBuild under a VS generator instead.
The target properties `CUDA_SEPARABLE_COMPILATION` and `CUDA_PTX_COMPILATION`
now aren't mutually exclusive and can now be used together on the same
target.
The `.elf` extension is a common convention used for embedded binaries.
Both Arm and RISC-V use the ELF file format for executables.
Configuring the `.elf` file extension is typically done incorrectly.
Most embedded developers set this in toolchain files, which is not
the correct place.
This is typically accomplished through a hack by setting the individual
language file extensions for C, CXX, and ASM.
Multiple CMake issues in the past have been opened related to this.
* #16538
* #20163
* #17880
A platform module makes it simpler and less error prone for developers
targeting these ubiquitous bare-metal platforms.
This PR attempts to solve this globally with a generic platform.
This could also be solved by using more specific platform modules, such
as one for each of bare-metal Arm and RISC-V.
02b2607a5c Help: Add release note for MCST LCC compiler support
e5d9fce03f LCC: Add dedicated support for MCST LCC compiler
2b9ef77944 CPack/DEB: deal with broken dpkg-shlibdeps on E2K architecture
0995c75301 Tests/RPM: skip tests tat rely on debugedit if it's not found
ea55ac9a51 Tests/RunCMake/CommandLine: Deal with locales that are different from English
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6608
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
"OS Elbrus" (OSL for short), a reference Linux distro for E2K (Elbrus)
platform may have broken dpkg-shlibdeps, that doesn't specify
dependencies correctly. In this case, the only reliable way is to
explicitly set dependencies of libc6 and lcc-libs, and then warn user
to let him know this list may be incomplete. This commit does that.
This fix has no effect on correctly working dpkg-shlibdeps, so when
this bug will be fixed in new versions of OSL, CPack will work as
expected with these distros.
VS 2022 Preview 5 renamed the redist directories from `Microsoft.VC142.*`
to `Microsoft.VC143.*` in order to match the `v143` toolset name.
Fixes: #22586
Revert commit 798c1c3192 (GNUInstallDirs: Comply with Debian Policy on
LIBEXECDIR, 2020-10-08, v3.19.0-rc1~11^2).
The Debian Policy builds upon FHS 3.0 and permits installing to
`/usr/libexec`. While Policy does grant an additional exception for
applications to use a single subdirectory of `/usr/lib/<triplet>`, this
is not meant to replace `/usr/libexec` as valid target.
Fixes: #22731
In commit 3aaf1d91bf (MSVC: C++20 final flag, C++23 support, 2021-05-29,
v3.20.4~7^2~1) we forgot to add `cxx_std_23` to the fallback table for
MSVC versions from VS 2010 through VS 2015. This allows project to at
least attempt compilation with these compilers since they do not have
any modes.
Issue: #22729
3add62462c Xcode: Fix detection of default language standard when given -std= flags
5c4424e5b7 CMakeDetermineCompilerId: Tolerate variables named for languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Merge-request: !6598
If one uses `CFLAGS='-std=...'` or `CXXFLAGS='-std=...'` then the given
`-std=` flag(s) will always be used. That effectively changes the
compiler default standard level and extension settings. Fix the
Xcode generator's compiler id logic to preserve any `-std=` flag
so that the proper defaults are detected.
This problem was exposed by commit 4a0485be7f (cmStandardLevelResolver:
Avoid unnecessary flags, fix unset level logic, 2021-05-29), which
changed the logic to not pass any `-std=` flag if the standard level
and extension settings requested by the project match the default
(`stdIt <= defaultStdIt` became `stdIt < defaultStdIt`). The new
logic assumes the detected default standard matches what will actually
happen when the project is generated.
64038fd5bc Help: Add release notes for Find{BLAS,LAPACK} BLA_SIZEOF_INTEGER option
972489ae4e Find{BLAS,LAPACK}: Provide testing of BLA_SIZEOF_INTEGER
95219365ff Find{BLAS,LAPACK}: Make possible testing of ILP64 model
2cd94f3e57 Find{BLAS,LAPACK}: Specify integer type in tests
9b69307b56 Find{BLAS,LAPACK}: De-duplicate and generalize test creation logic
91fd645d46 FindLAPACK: Stop processing if LAPACK library does not have 64-bit integer API
b8a3cea51f FindBLAS: Stop processing if BLAS library does not have 64-bit integer API
d2f5c7856f FindLAPACK: Search 32/64-bit integer API via BLA_SIZEOF_INTEGER if possible
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6407
1851aa49be FetchContent: Pass through networking-related CMAKE_... variables
96937438b7 Help: Clean up how TLS and NETRC variables are discussed
2a82bd85b6 Help: Add documentation for CMAKE_TLS_CAINFO
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6589
