CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-02-20T16:28:55-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/16222CMAKE_<lang>_VISIBILITY_PRESET is ignored with GCC 4.12018-02-20T16:28:55-05:00Nick HutchinsonCMAKE_<lang>_VISIBILITY_PRESET is ignored with GCC 4.1When compiling with GCC 4.1, it's not possible to affect symbol visibility using `CMAKE_<lang>_VISIBILITY_PRESET` or `<lang>_VISIBILITY_PRESET`. It appears this is due to a version check in `Compiler/GNU.cmake`:
```
if(NOT CMAKE_${...When compiling with GCC 4.1, it's not possible to affect symbol visibility using `CMAKE_<lang>_VISIBILITY_PRESET` or `<lang>_VISIBILITY_PRESET`. It appears this is due to a version check in `Compiler/GNU.cmake`:
```
if(NOT CMAKE_${lang}_COMPILER_VERSION VERSION_LESS 4.2)
set(CMAKE_${lang}_COMPILE_OPTIONS_VISIBILITY "-fvisibility=")
endif()
```
I'm not precisely sure when GCC added support for `-fvisibility=...`, but I've used it successfully with GCC 4.1. I'm working around this by adding `-fvisibility=...` using `add_compile_options()`.
Tested with CMake 3.4.3, but observed that this is unchanged in CMake 3.6.3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/17740CompileFeatures test fails with gcc 82018-02-22T11:24:10-05:00Orion PoplawskiCompileFeatures test fails with gcc 8```
33: Scanning dependencies of target default_dialect_C
33: [ 13%] Building C object CMakeFiles/default_dialect_C.dir/default_dialect.c.o
33: /builddir/build/BUILD/cmake-3.10.2/Tests/CompileFeatures/default_dialect.c:4:2: error: #error...```
33: Scanning dependencies of target default_dialect_C
33: [ 13%] Building C object CMakeFiles/default_dialect_C.dir/default_dialect.c.o
33: /builddir/build/BUILD/cmake-3.10.2/Tests/CompileFeatures/default_dialect.c:4:2: error: #error Unexpected value for __STDC_VERSION__.
33: #error Unexpected value for __STDC_VERSION__.
33: ^~~~~
```
This is happening as part of Fedora 28 development.3.11.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20752PCH+ifort: cmake_pch.cxx.o created instead of cmake_pch.hxx.gch when language...2020-06-03T06:04:44-04:00Pavel LiavonauPCH+ifort: cmake_pch.cxx.o created instead of cmake_pch.hxx.gch when language Fortran is added to project and ifort detected.With next code there is no error.
```
project(test CXX)
target_precompile_headers(${PROJECT_NAME} PRIVATE
"$<$<COMPILE_LANGUAGE:CXX>:${CMAKE_CURRENT_SOURCE_DIR}/stdafx-UnitTest.h>"
)
add_executable(... only cpp)
```
But when I cha...With next code there is no error.
```
project(test CXX)
target_precompile_headers(${PROJECT_NAME} PRIVATE
"$<$<COMPILE_LANGUAGE:CXX>:${CMAKE_CURRENT_SOURCE_DIR}/stdafx-UnitTest.h>"
)
add_executable(... only cpp)
```
But when I change project to
```project(test CXX Fortran)```
cmake detects ifort and leads to next error on linking executable on linux with g++.
`cmake_pch.cxx.o: file not recognized: File format not recognized`
With further investigation I found that. with adding Fortran language cmake builds cmake_pch.cxx.o target instead of cmake_pch.hxx.gch for CXX language.
CMake should build gch in both cases.
I'm using CMake 3.17.2 with GCC 5.3.3.17.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21275GCC 10 breaks compile flag detection2020-10-07T07:12:37-04:00LuthafGCC 10 breaks compile flag detectionAll my apologies if this is already known, I could not find another issue about this.
The REGEX_FAIL currently used to check invalid GCC flags (https://gitlab.kitware.com/cmake/cmake/-/blob/b1898bf97570b2887f7398105231ff72adb1564d/Modul...All my apologies if this is already known, I could not find another issue about this.
The REGEX_FAIL currently used to check invalid GCC flags (https://gitlab.kitware.com/cmake/cmake/-/blob/b1898bf97570b2887f7398105231ff72adb1564d/Modules/CheckCompilerFlag.cmake#L48) is broken with GCC 10 which emit warnings looking like `command-line option .* is valid for .* but not for` (notice the additional dash between command and line). The message was updated recently: https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/opts-global.c;h=0ecf545c6e542cc5eee78eac97d200b55e11001f.
I would be happy to send a Merge request to update the regex to `command[ -]line option .* is valid for .* but not for XXX` instead.3.19.0https://gitlab.kitware.com/cmake/cmake/-/issues/22013Cannot compile on Centos7.8 with gcc/9.1.02021-04-06T08:28:30-04:00Сергей ЖуматийCannot compile on Centos7.8 with gcc/9.1.0I'm trying to compile cmake on Centos 7.8. I'm using compiled gcc-9.1.0 and get this error (and some similar later):
```
[ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_random.c.o
/root/dow...I'm trying to compile cmake on Centos 7.8. I'm using compiled gcc-9.1.0 and get this error (and some similar later):
```
[ 37%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_random.c.o
/root/downl/cmake-3.20.0/Utilities/cmlibarchive/libarchive/archive_random.c:176:16: error: unknown type name ‘u_char’; did you mean ‘char’?
176 | arc4_addrandom(u_char *dat, int datlen)
| ^~~~~~
| char
```3.20.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22453GNU: Incorrect flag for C232021-07-23T09:40:40-04:00Daniel BelowGNU: Incorrect flag for C23In CMake 3.21.0 the generated flag for C23 seems incorrect for GCC: https://gitlab.kitware.com/cmake/cmake/-/blob/b9c3acac02b6202359e6964853521878e386ed06/Modules/Compiler/GNU-C.cmake#L45
It generates `-std=gnu23` instead of `-std=gnu2x...In CMake 3.21.0 the generated flag for C23 seems incorrect for GCC: https://gitlab.kitware.com/cmake/cmake/-/blob/b9c3acac02b6202359e6964853521878e386ed06/Modules/Compiler/GNU-C.cmake#L45
It generates `-std=gnu23` instead of `-std=gnu2x`. Neither GCC trunk, nor GCC 9.1 as mentioned in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5783/diffs?commit_id=b658ef187976a01e49d78cb3c447851a48144dc5, seem to work with `-std=gnu23`: https://godbolt.org/z/7zbo5rjfa
Note: for clang it works: https://gitlab.kitware.com/cmake/cmake/-/blob/b9c3acac02b6202359e6964853521878e386ed06/Modules/Compiler/Clang-C.cmake#L513.21.1Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22490Support for Mac OS X 10.4 broken since v. 3.202021-09-23T10:24:27-04:00Evan MillerSupport for Mac OS X 10.4 broken since v. 3.20As of CMake 3.20.1, `-rpath` is being added to the linker command when targeting all Apple platforms. However, `ld` will return an error when `-rpath` is combined with `-mmacosx-version-min=10.4`. The pre-3.20.1 behavior should be restor...As of CMake 3.20.1, `-rpath` is being added to the linker command when targeting all Apple platforms. However, `ld` will return an error when `-rpath` is combined with `-mmacosx-version-min=10.4`. The pre-3.20.1 behavior should be restored when targeting Mac OS 10.4 and earlier.
Downstream report: https://trac.macports.org/ticket/632613.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22487LINK_WHAT_YOU_USE adds -Wl,--no-as-needed to static libraries2021-08-07T08:08:07-04:00ajpennerLINK_WHAT_YOU_USE adds -Wl,--no-as-needed to static librariesWhen I enable the LINK_WHAT_YOU_USE option with cmake version 3.21.* I am finding that this now adds the "-Wl,--no-as-needed" linker option to the archiver used for static libraries. This option is not valid for the archiver and as a res...When I enable the LINK_WHAT_YOU_USE option with cmake version 3.21.* I am finding that this now adds the "-Wl,--no-as-needed" linker option to the archiver used for static libraries. This option is not valid for the archiver and as a result the build fails. If I rollback my cmake version to 3.18.5 everything works as expected. I am operating on production code so I did not pin down the exact version that exposes this bug.3.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22224`CXX_EXTENSIONS OFF` does not turn off extensions in GCC 112021-11-12T09:02:45-05:00Pedro Fonini`CXX_EXTENSIONS OFF` does not turn off extensions in GCC 11Using CMake 3.20.2; this has been described here: https://stackoverflow.com/questions/67641124/gcc-11-how-to-tell-cmake-i-dont-want-the-default-c-gnu-extensions
GCC 11's default ISO C++ standard is C++17, so that when I declare `target_...Using CMake 3.20.2; this has been described here: https://stackoverflow.com/questions/67641124/gcc-11-how-to-tell-cmake-i-dont-want-the-default-c-gnu-extensions
GCC 11's default ISO C++ standard is C++17, so that when I declare `target_compile_features(mytarget cxx_std_17)` CMake (correctly) does not generate any `-std` flag. However, GCC's default is actually `-std=gnu++17`, and if I want `-std=c++17` I should be able to declare `set_target_properties(mytarget PROPERTIES CXX_EXTENSIONS OFF)`. Unfortunately, this has no effect, and CMake still omits the `-std` flag.3.22.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/23123FortranCInterface/Detect: Broken with GCC 12.0 and LTO enabled2022-05-18T13:48:34-04:00Björn EsserFortranCInterface/Detect: Broken with GCC 12.0 and LTO enabledFortran/C interface detection is broken when LTO is enabled with GCC (gfortran) 12.0.
Minimal reproducer:
CMakeLists.txt:
```
PROJECT(F-C-MWE LANGUAGES C Fortran)
include(FortranCInterface)
FortranCInterface_HEADER(FCMangle.h
...Fortran/C interface detection is broken when LTO is enabled with GCC (gfortran) 12.0.
Minimal reproducer:
CMakeLists.txt:
```
PROJECT(F-C-MWE LANGUAGES C Fortran)
include(FortranCInterface)
FortranCInterface_HEADER(FCMangle.h
MACRO_NAMESPACE "FC_"
SYMBOL_NAMESPACE "FC_"
SYMBOLS mysub mymod:my_sub)
FortranCInterface_VERIFY()
```
On shell:
```
export CFLAGS='-flto'
export FFLAGS='-flto'
export FCFLAGS='-flto'
cmake .
```
Result (some lines suppressed for legibility):
```
-- Detecting Fortran/C Interface - Failed to recognize symbols
CMake Warning (dev) at /usr/share/cmake/Modules/FortranCInterface.cmake:309 (message):
No FortranCInterface mangling known for mysub
CMake Warning (dev) at /usr/share/cmake/Modules/FortranCInterface.cmake:295 (message):
No FortranCInterface mangling known for mymod:my_sub
-- Verifying Fortran/C Compiler Compatibility
CMake Warning (dev) at /usr/share/cmake/Modules/FortranCInterface.cmake:309 (message):
No FortranCInterface mangling known for VerifyFortran
-- Verifying Fortran/C Compiler Compatibility - Failed
CMake Error at /usr/share/cmake/Modules/FortranCInterface.cmake:391 (message):
/usr/bin/ld: /tmp/cclMYidY.ltrans0.ltrans.o: in function `main':
/usr/share/cmake/Modules/FortranCInterface/Verify/main.c:14: undefined reference to `VerifyFortran'
collect2: error: ld returned 1 exit status
```3.22.2https://gitlab.kitware.com/cmake/cmake/-/issues/23836IPO: gcc -flto=auto breaks linking on Windows2022-08-15T10:48:31-04:00Brad KingIPO: gcc -flto=auto breaks linking on Windows!7400 switched from `-flto` to `-flto=auto` for #23640, but according to https://gitlab.kitware.com/cmake/cmake/-/issues/23640#note_1227490 the latter flag breaks linking on Windows.!7400 switched from `-flto` to `-flto=auto` for #23640, but according to https://gitlab.kitware.com/cmake/cmake/-/issues/23640#note_1227490 the latter flag breaks linking on Windows.3.24.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/25263macOS, GNU toolchain: unable to link with target framework when SYSTEM proper...2023-09-22T09:07:14-04:00Marc ChevriermacOS, GNU toolchain: unable to link with target framework when SYSTEM property is trueMR !8758 add the support of SYSTEM frameworks by specifying option `-iframework` rather than `-F` for compile and link steps.
Unfortunately, GNU compilers do not propagate this option to the linker, which prevents correct link: framewo...MR !8758 add the support of SYSTEM frameworks by specifying option `-iframework` rather than `-F` for compile and link steps.
Unfortunately, GNU compilers do not propagate this option to the linker, which prevents correct link: frameworks are no longer founded. For information, `AppleClang` delivers option `-F` to the linker when the option `iframework` is specified.
So, the obvious solution is to provide option `-F` for the link step regardless the SYSTEM target property.3.28.0https://gitlab.kitware.com/cmake/cmake/-/issues/25511Issue with C++ modules and gcc2024-02-16T09:33:23-05:00FVIssue with C++ modules and gccHello, the following behaves as expected with clang but not with gcc trunk.
I had a look at what ninja is doing but I am not able to figure out if this a ninja or cmake or gcc issue.
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3....Hello, the following behaves as expected with clang but not with gcc trunk.
I had a look at what ninja is doing but I am not able to figure out if this a ninja or cmake or gcc issue.
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.28) # With 3.28, no need for set(CMAKE_CXX_SCAN_FOR_MODULES ON).
project(std_module_example CXX)
set(CMAKE_CXX_STANDARD 20)
# Default to C++ extensions being off. Clang's modules support have trouble
# with extensions right now and it is not required for any other compiler
set(CMAKE_CXX_EXTENSIONS OFF)
add_library(foo)
target_sources(foo
PRIVATE
foo_impl.cxx
PUBLIC
FILE_SET cxx_modules TYPE CXX_MODULES FILES
foo.cxx
)
add_executable(hello main.cxx)
target_link_libraries(hello PRIVATE foo)
```
main.cxx:
```
import foo;
int main() {
foo f;
f.helloworld();
return 0;
}
```
foo.cxx:
```
module;
#include <iostream>
export module foo;
export class foo {
public:
foo();
~foo();
void helloworld();
};
export void fun() {
std::cout << "abc" << std::endl;
}
```
foo_impl.cxx:
```
module; // Start of the globl module fragment where #includes can happen
#include <iostream>
module foo;
foo::foo() = default;
foo::~foo() = default;
void foo::helloworld() { std::cout << "hello worldad \n"; }
```
The issue is that the second ninja invocation below rebuilds main.o and foo.o with gcc (clang handles this correctly):
```
rm -rf CMakeFiles/ CMakeCache.txt build.ninja libfoo.a hello cmake_install.cmake
cmake -DCMAKE_BUILD_TYPE=Debug -GNinja
ninja
touch foo_impl.cxx
ninja -v -d explain
```
Versions:
```
cmake --version
cmake version 3.28.0
ninja --version
1.12.0.git
# Build from source...
g++ -v
gcc version 14.0.0 20231211 (experimental) (GCC)
clang -v
clang version 16.0.0
```
I attached the ninja outputs for [clang](/uploads/4693b18c2c2ce07861386d679483c987/clang_build.txt) and [gcc](/uploads/60a4bef80a0fe92cfc79caa5741d3e5a/gcc_build.txt).3.28.4Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25514macOS/GCC: Incorrect flag on arm64 when precompiled headers are used2024-02-11T11:39:06-05:00Juha KuikkamacOS/GCC: Incorrect flag on arm64 when precompiled headers are usedcmake version 3.28.0
g++-13 (Homebrew GCC 13.2.0) 13.2.0
I have a test app that reproduces the issue but you need GCC (not sure if version is important) installed on your arm64 Mac computer. (Test app here https://github.com/kuikka/incl...cmake version 3.28.0
g++-13 (Homebrew GCC 13.2.0) 13.2.0
I have a test app that reproduces the issue but you need GCC (not sure if version is important) installed on your arm64 Mac computer. (Test app here https://github.com/kuikka/include_problem)
```
cmake --preset gcc
```
After configuring, trying to build fails:
```
% cmake --build out/build/gcc
[1/2] Building CXX object CMakeFiles/app.dir/main.cpp.o
FAILED: CMakeFiles/app.dir/main.cpp.o
/opt/homebrew/bin/g++-13 -I/Users/kuikka/dev/include_problem/. -g -std=gnu++20 -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk -Winvalid-pch -Xarch_arm64 -include/Users/kuikka/dev/include_problem/out/build/gcc/CMakeFiles/app.dir/cmake_pch_arm64.hxx -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c /Users/kuikka/dev/include_problem/main.cpp
g++-13: error: unrecognized command-line option '-Xarch_arm64'
ninja: build stopped: subcommand failed.
```
The failing option `-Xarch_arm64` is specific to clang and fails on gcc.
If I comment out the "target_precompile_headers" in CMakeLists.txt and reconfigure, the build succeeds.https://gitlab.kitware.com/cmake/cmake/-/issues/24935CMake randomly stops building correctly on OS X 12.62023-05-24T12:16:42-04:00Ricardo MatiasCMake randomly stops building correctly on OS X 12.6I don't know whats happening, but I have this project that randomly stops working and there's this `-search_paths_first` error pops up. It doesn't always happen and I can't figure out what exactly triggers it.
cmake version 3.26.4
Mac O...I don't know whats happening, but I have this project that randomly stops working and there's this `-search_paths_first` error pops up. It doesn't always happen and I can't figure out what exactly triggers it.
cmake version 3.26.4
Mac OS X 12.6.6
compiler: arm-none-eabi-gcc 10.3.1
```
[main] Configuring project: pirack
[proc] Executing command: /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=/Users/feral/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-g++ -S/Users/feral/Projects/DIY/pico/pirack -B/Users/feral/Projects/DIY/pico/pirack/build -G Ninja
[cmake] Using PICO_SDK_PATH from environment ('/Users/feral/Projects/DIY/pico/LIBRARIES/pico-sdk')
[cmake] Not searching for unused variables given on the command line.
[cmake] PICO_SDK_PATH is /Users/feral/Projects/DIY/pico/LIBRARIES/pico-sdk
[cmake] Defaulting PICO_PLATFORM to rp2040 since not specified.
[cmake] -- The CXX compiler identification is GNU 10.3.1
[cmake] -- The C compiler identification is GNU 10.3.1
[cmake] -- The ASM compiler identification is GNU
[cmake] -- Found assembler: /usr/local/bin/arm-none-eabi-gcc
[cmake] -- Checking whether CXX compiler has -isysroot
[cmake] -- Checking whether CXX compiler has -isysroot - yes
[cmake] -- Checking whether CXX compiler supports OSX deployment target flag
[cmake] -- Checking whether CXX compiler supports OSX deployment target flag - no
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - failed
[cmake] -- Check for working CXX compiler: /usr/local/bin/arm-none-eabi-g++
[cmake] -- Check for working CXX compiler: /usr/local/bin/arm-none-eabi-g++ - broken
[cmake] CMake Error at /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/CMakeTestCXXCompiler.cmake:60 (message):
[cmake] The C++ compiler
[cmake]
[cmake] "/usr/local/bin/arm-none-eabi-g++"
[cmake]
[cmake] is not able to compile a simple test program.
[cmake]
[cmake] It fails with the following output:
[cmake]
[cmake] Change Dir: /Users/feral/Projects/DIY/pico/pirack/build/CMakeFiles/CMakeScratch/TryCompile-K4bU0Z
[cmake]
[cmake] Run Build Command(s):/usr/local/bin/ninja -v cmTC_c8709 && [1/2] /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -o CMakeFiles/cmTC_c8709.dir/testCXXCompiler.cxx.o -c /Users/feral/Projects/DIY/pico/pirack/build/CMakeFiles/CMakeScratch/TryCompile-K4bU0Z/testCXXCompiler.cxx
[cmake] [2/2] : && /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/opencv@2/lib CMakeFiles/cmTC_c8709.dir/testCXXCompiler.cxx.o -o cmTC_c8709 && :
[cmake] FAILED: cmTC_c8709
[cmake] : && /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/opencv@2/lib CMakeFiles/cmTC_c8709.dir/testCXXCompiler.cxx.o -o cmTC_c8709 && :
[cmake] /usr/local/Cellar/arm-none-eabi-gcc/10.3-2021.07/gcc/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: Error: unable to disambiguate: -search_paths_first (did you mean --search_paths_first ?)
[cmake] collect2: error: ld returned 1 exit status
[cmake] ninja: build stopped: subcommand failed.
[cmake]
[cmake]
[cmake]
[cmake]
[cmake]
[cmake] CMake will not be able to correctly generate this project.
[cmake] Call Stack (most recent call first):
[cmake] CMakeLists.txt:9 (project)
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
[proc] The command: /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=/Users/feral/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-g++ -S/Users/feral/Projects/DIY/pico/pirack -B/Users/feral/Projects/DIY/pico/pirack/build -G Ninja exited with code: 1
```https://gitlab.kitware.com/cmake/cmake/-/issues/24842Winelib (winegcc/wineg++) support2023-04-23T23:43:12-04:00Mingye WangWinelib (winegcc/wineg++) supportI saw [RFC: Investigate the winegcc/wineg++ support in CMake (via CMakeParseImplicit[Include/Link]Info or Compiler/Wine-GNU etc.)?](https://discourse.cmake.org/t/rfc-investigate-the-winegcc-wineg-support-in-cmake-via-cmakeparseimplicit-i...I saw [RFC: Investigate the winegcc/wineg++ support in CMake (via CMakeParseImplicit[Include/Link]Info or Compiler/Wine-GNU etc.)?](https://discourse.cmake.org/t/rfc-investigate-the-winegcc-wineg-support-in-cmake-via-cmakeparseimplicit-include-link-info-or-compiler-wine-gnu-etc/6589) by Alex but noticed that it has no issue actually filed after @ben.boeckel's suggestion, so here it is.
As Alex mentioned, winegcc is about linking to Windows libs in native (non-Windows) executables, and the library search routine needs to adapt somewhat. Well, winegcc potentially links to native `.so` (and `.dylib`) too per https://github.com/wine-mirror/wine/blob/7f90c9d7eb08891394f5d48448fd1a6cb5a67df9/tools/winegcc/winegcc.c#L916. All the types it looks for is in [`guess_lib_type()`](https://github.com/wine-mirror/wine/blob/7f90c9d7eb08891394f5d48448fd1a6cb5a67df9/tools/winegcc/utils.c#L120).
https://bugs.winehq.org/show_bug.cgi?id=51793 is a related issue tracking this thing on the Wine side.https://gitlab.kitware.com/cmake/cmake/-/issues/24671Ninja: Fail to build static libraries for ar-gcc based ARs2023-04-04T10:12:06-04:00mtribiereNinja: Fail to build static libraries for ar-gcc based ARsConfiguration:
- Cross-compilation
- Ninja
- Gcc-like compiler
- Gcc-like AR
- Windows environment
Some ar-gcc based AR programs are picky and only allow RSP files with the format of **one file per line**.
This is archived in Ninja b...Configuration:
- Cross-compilation
- Ninja
- Gcc-like compiler
- Gcc-like AR
- Windows environment
Some ar-gcc based AR programs are picky and only allow RSP files with the format of **one file per line**.
This is archived in Ninja by using the `$in_newline` instruction. However by default, on a Windows environment with a Gcc-like compiler, the generated Ninja always uses `$in`. Which **causes the RSP to not be recognized** by the AR command, and the build to fail.
There should be a way that allow to specify the RSP format.
This would allow more flexibility for those AR programs.https://gitlab.kitware.com/cmake/cmake/-/issues/24653FreeBSD: precompiled headers failure when built with gcc-122023-03-30T10:01:29-04:00yurivictFreeBSD: precompiled headers failure when built with gcc-12I am trying to use precompiled headers for mlpack.hpp installed by the mlpack project https://github.com/mlpack/mlpack
CMakeLists.txt is like this:
```
cmake_minimum_required(VERSION 3.15.4)
project(X)
find_package(PkgConfig REQUIRED)
...I am trying to use precompiled headers for mlpack.hpp installed by the mlpack project https://github.com/mlpack/mlpack
CMakeLists.txt is like this:
```
cmake_minimum_required(VERSION 3.15.4)
project(X)
find_package(PkgConfig REQUIRED)
pkg_check_modules(mlpack REQUIRED mlpack)
add_executable(x-target
module1.cpp
module2.cpp
)
target_include_directories(x-target PUBLIC
${mlpack_CFLAGS}
)
target_precompile_headers(x-target PUBLIC
${CMAKE_INSTALL_PREFIX}/include/mlpack.hpp
)
target_link_libraries(x-target
${mlpack_LDFLAGS}
)
add_definitions(-DMLPACK_ENABLE_ANN_SERIALIZATION) # just for target_precompile_headers
```
When compiler is gcc-12 the above cmake file causes build failure:
```
$ make
[ 6%] Building CXX object src/CMakeFiles/x-target.dir/cmake_pch.hxx.gch
[ 13%] Building CXX object src/CMakeFiles/x-target.dir/module1.cpp.o
<command-line>: sorry, unimplemented: PCH allocation failure
*** Error code 1
```
cmake-core-3.25.1
FreeBSD 13.1https://gitlab.kitware.com/cmake/cmake/-/issues/24630C++ Modules: clang-scan-deps + gcc2023-03-29T10:24:34-04:00huangqinjinC++ Modules: clang-scan-deps + gccI am trying to use clang-scan-deps from LLVM 16 as the scanner for gcc. The possibility is mentioned in https://gitlab.kitware.com/cmake/cmake/-/issues/18355#note_1316796.
- OS: Linux
- LLVM: 16
- GCC: 12.2
- CMake: 3.26
- Ninja: 1.11.1...I am trying to use clang-scan-deps from LLVM 16 as the scanner for gcc. The possibility is mentioned in https://gitlab.kitware.com/cmake/cmake/-/issues/18355#note_1316796.
- OS: Linux
- LLVM: 16
- GCC: 12.2
- CMake: 3.26
- Ninja: 1.11.1
- Repo: https://github.com/huangqinjin/cxxmodules
Build the `named-module` project and fails with messages:
```shell
$ cmake --build . --target named-module -- -v
[1/6] /opt/llvm-16/bin/clang-scan-deps -format=p1689 -- /opt/llvm-16/bin/clang++ -g -std=c++20 -x c++ /home/huangqinjin/Projects/cxxmodules/named-module/main.cpp -c -o named-module/CMakeFiles/named-module.dir/main.cpp.o -MT named-module/CMakeFiles/named-module.dir/main.cpp.o.ddi -MD -MF named-module/CMakeFiles/named-module.dir/main.cpp.o.ddi.d > named-module/CMakeFiles/named-module.dir/main.cpp.o.ddi
[2/6] /opt/llvm-16/bin/clang-scan-deps -format=p1689 -- /opt/llvm-16/bin/clang++ -g -std=c++20 -x c++ /home/huangqinjin/Projects/cxxmodules/named-module/hello.cppm -c -o named-module/CMakeFiles/named-module.dir/hello.cppm.o -MT named-module/CMakeFiles/named-module.dir/hello.cppm.o.ddi -MD -MF named-module/CMakeFiles/named-module.dir/hello.cppm.o.ddi.d > named-module/CMakeFiles/named-module.dir/hello.cppm.o.ddi
[3/6] /opt/cmake/bin/cmake -E cmake_ninja_dyndep --tdi=named-module/CMakeFiles/named-module.dir/CXXDependInfo.json --lang=CXX --modmapfmt=gcc --dd=named-module/CMakeFiles/named-module.dir/CXX.dd @named-module/CMakeFiles/named-module.dir/CXX.dd.rsp
[4/6] /usr/bin/g++-12 -g -std=c++20 -MD -MT named-module/CMakeFiles/named-module.dir/hello.cppm.o -MF named-module/CMakeFiles/named-module.dir/hello.cppm.o.d -fmodules-ts -fmodule-mapper=named-module/CMakeFiles/named-module.dir/hello.cppm.o.modmap -x c++ -o named-module/CMakeFiles/named-module.dir/hello.cppm.o -c /home/huangqinjin/Projects/cxxmodules/named-module/hello.cppm
FAILED: named-module/CMakeFiles/named-module.dir/hello.cppm.o named-module/CMakeFiles/named-module.dir/hello.gcm
/usr/bin/g++-12 -g -std=c++20 -MD -MT named-module/CMakeFiles/named-module.dir/hello.cppm.o -MF named-module/CMakeFiles/named-module.dir/hello.cppm.o.d -fmodules-ts -fmodule-mapper=named-module/CMakeFiles/named-module.dir/hello.cppm.o.modmap -x c++ -o named-module/CMakeFiles/named-module.dir/hello.cppm.o -c /home/huangqinjin/Projects/cxxmodules/named-module/hello.cppm
inputs may not also have inputs
ninja: build stopped: subcommand failed.
```
### Edit
No error after adding `-Mno-modules`.
```cmake
set(CMAKE_EXPERIMENTAL_CXX_MODULE_MAP_FLAG "-fmodules-ts -Mno-modules -fmodule-mapper=<MODULE_MAP_FILE> -x c++")
```https://gitlab.kitware.com/cmake/cmake/-/issues/23105Apple: ARM GCC toolchain (arm-none-eabi-gcc) on Apple Silicon (M1)2023-12-10T03:04:39-05:00Arthur WesleyApple: ARM GCC toolchain (arm-none-eabi-gcc) on Apple Silicon (M1)ARM GCC toolchain compiler fails cmake "Check for working C compiler" on Apple Silicon (M1)
The [ARM GCC toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm), a version of GC...ARM GCC toolchain compiler fails cmake "Check for working C compiler" on Apple Silicon (M1)
The [ARM GCC toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm), a version of GCC used for embedded development, does not support the `-arch` option that many other compilers support. On Apple M1 chips, CMake automatically appends the `-arch` flag to the "Checking for working C/C++ compiler" step of the build process. This causes CMake to be unable to run the compiler on Apple silicon resulting in issues brought up for [the ARM GCC toolchain homebrew](https://github.com/ARMmbed/homebrew-formulae/issues/32) and [for raspberry pi](https://forums.raspberrypi.com/viewtopic.php?t=310385).
The error is as follows:
```cerr
-- The C compiler identification is GNU 10.3.1
-- The CXX compiler identification is GNU 10.3.1
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - no
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /opt/homebrew/bin/arm-none-eabi-gcc
-- Check for working C compiler: /opt/homebrew/bin/arm-none-eabi-gcc - broken
CMake Error at /.../CMakeTestCCompiler.cmake:69 (message):
The C compiler
"/opt/homebrew/bin/arm-none-eabi-gcc"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/arthur/CLionProjects/test/cmake-build-debug-msp432/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make -f Makefile cmTC_8747d/fast && /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/cmTC_8747d.dir/build.make CMakeFiles/cmTC_8747d.dir/build
Building C object CMakeFiles/cmTC_8747d.dir/testCCompiler.c.o
/opt/homebrew/bin/arm-none-eabi-gcc -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk -o CMakeFiles/cmTC_8747d.dir/testCCompiler.c.o -c /Users/arthur/CLionProjects/test/cmake-build-debug-msp432/CMakeFiles/CMakeTmp/testCCompiler.c
arm-none-eabi-gcc: error: arm64: No such file or directory
arm-none-eabi-gcc: error: unrecognized command-line option '-arch'; did you mean '-march='?
make[1]: *** [CMakeFiles/cmTC_8747d.dir/testCCompiler.c.o] Error 1
make: *** [cmTC_8747d/fast] Error 2
CMake will not be able to correctly generate this project.
```
This issue occurs with CMake 3.22.1