CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-01-10T16:04:19-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/11704[mingw32] mingw32-make install: CMAKE_INSTALL_PREFIX and DESTDIR issue2017-01-10T16:04:19-05:00Kitware Robot[mingw32] mingw32-make install: CMAKE_INSTALL_PREFIX and DESTDIR issueThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11704). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11704). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/16879cmake-3.8 build failed with mingw-w642017-05-16T11:44:33-04:00Aleksey Chernovcmake-3.8 build failed with mingw-w64Starting with cmake-3.8.0 building on mingw-w64 failed. cmake-3.8.1 also affected.
```
./bootstrap --parallel=5 --prefix=/mingw --system-libs --no-system-jsoncpp --no-qt-gui
...
g++ -I/build/cmake-3.8.1/Bootstrap.cmk -I/build/cmake-3....Starting with cmake-3.8.0 building on mingw-w64 failed. cmake-3.8.1 also affected.
```
./bootstrap --parallel=5 --prefix=/mingw --system-libs --no-system-jsoncpp --no-qt-gui
...
g++ -I/build/cmake-3.8.1/Bootstrap.cmk -I/build/cmake-3.8.1/Source -I/build/cmake-3.8.1/Utilities -c /build/cmake-3.8.1/Source/cmFindFileCommand.cxx -o cmFindFileCommand.o
D:/msys2_x64/build/cmake-3.8.1/Source/cmFileCommand.cxx: In function 'std::__cxx11::string fix_file_url_windows(const string&)':
D:/msys2_x64/build/cmake-3.8.1/Source/cmFileCommand.cxx:84:29: error: 'CP_ACP' was not declared in this scope
WideCharToMultiByte(CP_ACP, 0, wurl.c_str(), -1, NULL, 0, NULL, NULL);
^~~~~~
D:/msys2_x64/build/cmake-3.8.1/Source/cmFileCommand.cxx:84:9: error: 'WideCharToMultiByte' was not declared in this scope
WideCharToMultiByte(CP_ACP, 0, wurl.c_str(), -1, NULL, 0, NULL, NULL);
^~~~~~~~~~~~~~~~~~~
g++ -I/build/cmake-3.8.1/Bootstrap.cmk -I/build/cmake-3.8.1/Source -I/build/cmake-3.8.1/Utilities -c /build/cmake-3.8.1/Source/cmFindLibraryCommand.cxx -o cmFindLibraryCommand.o
make: *** [Makefile:108: cmFileCommand.o] Ошибка 1
make: *** Ожидание завершения заданий…
```
Using:
* gcc-7.1.0, gcc-6.3.0
* mingw-w64-5.0.2
My version of patch in attachments.
P.S. I'm using my own build tool, than also install all necessary dependencies (including toolchain) for cmake (https://sourceforge.net/projects/mingwportage/). This tool is similar to gentoo's emerge.
[cmake-3.8.1-mingw.patch](/uploads/d6f2ad749a41de659c6bc604880a0510/cmake-3.8.1-mingw.patch)3.8.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16893Ninja generator doesn’t work in msys2-built cmake2017-05-26T11:17:20-04:00Norbert PfeilerNinja generator doesn’t work in msys2-built cmakeThe problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to...The problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to work with mingw-w64 which results in an inability for the generator to produce any files.
`codecvt::do_out` always returns `std::codecvt::error` when a range of more than 1 char is passed.
Changing [this condition](https://gitlab.kitware.com/cmake/cmake/blob/6b05e028f1a3afc7906908bd48d58993da02a9d9/Source/cm_codecvt.cxx#L61) to `>= 1` seems to fix it.
I’m not sure why it should work the way it currently is at all.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16959Building cmake-3.9.0-rc2 with MinGW fails2017-06-12T10:08:40-04:00Ghost UserBuilding cmake-3.9.0-rc2 with MinGW failscmake-3.9.0-rc2 builds with Visual Studio 2017 but with the current MinGW I had a few problems summarised below.
1) Source/bindexplib.cxx
`#include <initguid.h>` needed for CLSID definition.
2) Source/kwsys/SystemInformation.cxx
Th...cmake-3.9.0-rc2 builds with Visual Studio 2017 but with the current MinGW I had a few problems summarised below.
1) Source/bindexplib.cxx
`#include <initguid.h>` needed for CLSID definition.
2) Source/kwsys/SystemInformation.cxx
The following enums (and derived pointer types) are not declared in
the MinGW headers:
enum LOGICAL_PROCESSOR_RELATIONSHIP
enum PROCESSOR_CACHE_TYPE
enum CACHE_DESCRIPTOR
3) Utilities/cmlibarchive/libarchive/archive_entry.c
Changed ssize_t to la_ssize_t in two function headers
to match the header file:
archive_entry_acl_to_text_w(struct archive_entry *entry, `la_ssize_t` *len, ...
archive_entry_acl_to_text(struct archive_entry *entry, `la_ssize_t` *len, ...
4) Utilities/cmlibarchive/libarchive/archive_read.c
Changed ssize_t to la_ssize_t in function header
to match the header file:
`la_ssize_t`
archive_read_data(struct archive *_a, void *buff, size_t s)
5) Utilities/cmlibarchive/libarchive/archive_virtual.c
Changed ssize_t to la_ssize_t in two function headers
to match the header file:
`la_ssize_t`
archive_write_data(struct archive *a, const void *buff, size_t s)
`la_ssize_t`
archive_write_data_block(struct archive *a, const void *buff, size_t s, int64_t o)
6) Utilities/cmlibarchive/libarchive/archive_write.c
Changed ssize_t to la_ssize_t in two function headers
to match the header file:
static `la_ssize_t` _archive_write_data(struct archive *, const void *, size_t);
static `la_ssize_t`
_archive_write_data(struct archive *_a, const void *buff, size_t s)
7) Utilities/cmlibuv/src/win/tty.c
Added definition for InterlockedOr (not in MinGW).
8) Utilities/cmvssetup/Setup.Configuration.h
`#include <oleauto.h>` for SysAllocStringByteLen and SysStringByteLen
(required in Source/cmVSSetuphelper.h).https://gitlab.kitware.com/cmake/cmake/-/issues/13803Ninja: cmake generates RSP_FILE with back slashes for ninja2018-12-07T09:58:43-05:00Kitware RobotNinja: cmake generates RSP_FILE with back slashes for ninjaThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13803). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13803). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/16727CodeLite + MinGW Makefile generator does not properly detect CPU count2019-11-19T11:30:26-05:00Alex MayfieldCodeLite + MinGW Makefile generator does not properly detect CPU countPretty much what it says on the tin. I tried creating a CodeLite project file on Windows 10 with CMake 3.7.2, and to my surprise, the resulting CodeLite project file passed `-j 0` to all invocations of `mingw32-make`.Pretty much what it says on the tin. I tried creating a CodeLite project file on Windows 10 with CMake 3.7.2, and to my surprise, the resulting CodeLite project file passed `-j 0` to all invocations of `mingw32-make`.https://gitlab.kitware.com/cmake/cmake/-/issues/20021Clang/LLVM-MinGW: Implicit include directories detected with newlines2019-12-16T10:40:23-05:00Cristian AdamClang/LLVM-MinGW: Implicit include directories detected with newlinesThe [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain is producing the following `CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES` entry in `CMakeCXXCompiler.cmake`:
```cmake
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "C:/llvm...The [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain is producing the following `CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES` entry in `CMakeCXXCompiler.cmake`:
```cmake
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "C:/llvm-mingw/include/c++/v1
;C:/llvm-mingw/lib/clang/9.0.0/include
;C:/llvm-mingw/include
")
```
Which causes problems in identifying if an include path is part of the implicit include directories list.3.15.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20300MinGW: MSVC standard library usage requirements2020-02-04T13:28:22-05:00Daan De MeyerMinGW: MSVC standard library usage requirementsI opened https://gitlab.kitware.com/cmake/cmake/issues/19496 a while ago which was fixed by defaulting to C++14 on Windows when using the Clang GNU frontend. Now I'm noticing the same problem when using MinGW on Windows (errors in MSVC s...I opened https://gitlab.kitware.com/cmake/cmake/issues/19496 a while ago which was fixed by defaulting to C++14 on Windows when using the Clang GNU frontend. Now I'm noticing the same problem when using MinGW on Windows (errors in MSVC standard library headers because `-std=c++11` is used when setting `CXX_STANDARD 11`, `CXX_STANDARD_REQUIRED ON`, `CXX_EXTENSIONS OFF` and `target_compile_features(${TARGET} PUBLIC cxx_std_11)`). Can the same fix be used here?https://gitlab.kitware.com/cmake/cmake/-/issues/20386compile_commands.json produce a weird path style in 'command' section when us...2020-02-26T04:45:04-05:00xuburycompile_commands.json produce a weird path style in 'command' section when using "MSYS Makefiles"When using "MSYS Makefiles", I get compile_commands.json with filepath like /C/ instead of C:/ which causing confuision for language service such as clangd or ccls. In the CMakelists.txt, all inputted file path are windows style but got ...When using "MSYS Makefiles", I get compile_commands.json with filepath like /C/ instead of C:/ which causing confuision for language service such as clangd or ccls. In the CMakelists.txt, all inputted file path are windows style but got converted to /C/ whatsoever. Does it necessary? Can I somehow configure the output for compile_commands.json? In Unix Makefiles everthing is good but it casue other problem when I try to find package installed in msys2. Thanks in advance!
```
"directory": "G:/codes/DIASProject/build",
"command": "/C/msys64/mingw64/bin/x86_64-w64-mingw32-g++.exe -I/G/codes/DIASProject/src/include -I/G/codes/DIASProject/src/include/DIAS_HEADERS -g -o CMakeFiles/TcpClient.dir/src/tcptestclient/main.cpp.obj -c /G/codes/DIASProject/src/tcptestclient/main.cpp",
"file": "G:/codes/DIASProject/src/tcptestclient/main.cpp"
```https://gitlab.kitware.com/cmake/cmake/-/issues/20629mingw windres [target_include_directories] invalid take path with space2020-04-27T07:34:39-04:00Yuriy Levchenkomingw windres [target_include_directories] invalid take path with spaceHello, i use CMake 3.17.1 and have issue with [target_include_directories]
i try compile [freetype2](https://www.freetype.org/) and set ZLIB_INCLUDE_DIR with space
example:
```
set(ZLIB_INCLUDE_DIR "D:/Mengine/cmake/Depends_MinGW/../....Hello, i use CMake 3.17.1 and have issue with [target_include_directories]
i try compile [freetype2](https://www.freetype.org/) and set ZLIB_INCLUDE_DIR with space
example:
```
set(ZLIB_INCLUDE_DIR "D:/Mengine/cmake/Depends_MinGW/../../dependencies/configuration/MinGW Makefiles/Debug/zlib" CACHE STRING "ZLIB_INCLUDE_DIR" FORCE)
```
'freetype' have CMakeLists.txt next code line:
```
target_include_directories(freetype PRIVATE ${ZLIB_INCLUDE_DIRS})
```
if i compile this - i get "error: Makefiles\Debug\zlib: No such file or directory"
i try force change `${ZLIB_INCLUDE_DIRS}` in freetype CMakeLists.txt on my path. And get the some thing error.
`target_include_directories(freetype PRIVATE "D:/Mengine/cmake/Depends_MinGW/../../dependencies/configuration/MinGW Makefiles/Debug/zlib")`
```
CMAKE VERSION: 3.17.1
CMAKE_GENERATOR: MinGW Makefiles
CMAKE_CXX_COMPILER_ID: Clang
CMAKE_CXX_COMPILER: C:/msys64/mingw32/bin/clang++.exe
CMAKE_C_COMPILER_ID: Clang
CMAKE_C_COMPILER: C:/msys64/mingw32/bin/clang.exe
CMAKE_MAKE_PROGRAM: C:/msys64/mingw32/bin/mingw32-make.exe
CMAKE_SYSTEM_NAME: Windows
CMAKE_SYSTEM_VERSION: 10.0.17763
CMAKE_SYSTEM_PROCESSOR: AMD64
CMAKE_BUILD_TYPE: Debug
```
if i compile other toolschaine MSVC, Android and iOS - result successful!
Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/20854MinGW: file(GET_RUNTIME_DEPENDENCIES ... ERROR: "Failed to run dumpbin/objdum...2020-06-24T03:28:25-04:00jjELTMinGW: file(GET_RUNTIME_DEPENDENCIES ... ERROR: "Failed to run dumpbin/objdump on:"I am trying to get a hang of the `file(GET_RUNTIME_DEPENDENCIES ...` function and read the threads
- [Copying dependent DLLs to executable directory?](https://discourse.cmake.org/t/copying-dependent-dlls-to-executable-directory/852),
- [...I am trying to get a hang of the `file(GET_RUNTIME_DEPENDENCIES ...` function and read the threads
- [Copying dependent DLLs to executable directory?](https://discourse.cmake.org/t/copying-dependent-dlls-to-executable-directory/852),
- [Linux copying dependencies using file(GET_RUNTIME_DEPENDENCIES..)](https://discourse.cmake.org/t/linux-copying-dependencies-using-file-get-runtime-dependencies/946) and
- [file GET_RUNTIME_DEPENDENCIES - cannot access variables](https://discourse.cmake.org/t/file-get-runtime-dependencies-cannot-access-variables/278).
I started off with the example project [kpyrkosz/cmake_crosscompile](https://discourse.cmake.org/t/file-get-runtime-dependencies-cannot-access-variables/278/6) given in [comment #6](https://discourse.cmake.org/t/file-get-runtime-dependencies-cannot-access-variables/278/6) of the thread "file GET_RUNTIME_DEPENDENCIES - cannot access variables".
Running the `install` target I get the error:
```
C:/msys64/mingw64/bin/mingw32-make.exe -f CMakeFiles\Makefile2 preinstall
mingw32-make[1]: Entering directory '<PATH_TO_PROJECT>/cmake_crosscompile/build/eclipse_win_Debug/amd64'
mingw32-make[1]: Nothing to be done for 'preinstall'.
mingw32-make[1]: Leaving directory '<PATH_TO_PROJECT>/cmake_crosscompile/build/eclipse_win_Debug/amd64'
Install the project...
"C:\Program Files\CMake\bin\cmake.exe" -P cmake_install.cmake
-- Install configuration: "Debug"
CMake Error at cmake_install.cmake:41 (file):
file Failed to run dumpbin on:
demonstration
mingw32-make: *** [Makefile:93: install] Error 1
"C:/msys64/mingw64/bin/mingw32-make.exe install" terminated with exit code 2. Build might be incomplete.
```
I am using MinGW64 and found out I do not have `dumpbin` but `objdump` in my `%PATH%`. The `CMAKE_OBJDUMP` variable is correctly set to `CMAKE_OBJDUMP="C:/msys64/mingw64/bin/objdump.exe"`, but I still have to manually `set(CMAKE_GET_RUNTIME_DEPENDENCIES_TOOL objdump)` for `objdump` to be used instead of `dumpbin`. Now I at least get the error `file Failed to run objdump on:`
```
[100%] Built target demonstration
mingw32-make[1]: Leaving directory '<PATH_TO_PROJECT>/cmake_crosscompile/build/eclipse_win_Debug/amd64'
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_progress_start D:\Code\Misc\C++\Projects\cmake_crosscompile\build\eclipse_win_Debug\amd64\CMakeFiles 0
C:/msys64/mingw64/bin/mingw32-make.exe -f CMakeFiles\Makefile2 preinstall
mingw32-make[1]: Entering directory '<PATH_TO_PROJECT>/cmake_crosscompile/build/eclipse_win_Debug/amd64'
mingw32-make[1]: Nothing to be done for 'preinstall'.
mingw32-make[1]: Leaving directory '<PATH_TO_PROJECT>/cmake_crosscompile/build/eclipse_win_Debug/amd64'
Install the project...
"C:\Program Files\CMake\bin\cmake.exe" -P cmake_install.cmake
-- Install configuration: "Debug"
CMake Error at cmake_install.cmake:46 (file):
file Failed to run objdump on:
demonstration
mingw32-make: *** [Makefile:93: install] Error 1
"C:/msys64/mingw64/bin/mingw32-make.exe install" terminated with exit code 2. Build might be incomplete.
```
, which seems more reasonable.
How can I analyze what's wrong?https://gitlab.kitware.com/cmake/cmake/-/issues/21191Android: Can not enable rtti exceptions with MinGW generator2020-09-16T22:28:01-04:00ShyJAndroid: Can not enable rtti exceptions with MinGW generatorHi,
I hava been trying to compile a lib using CMake 3.18 + MinGW64 + NDK r21b.
I hava tried `ANDROID_CPP_FEATURES="rtti exception"` and `ANDROID_STL_FORCE_FEATURES` to enable rtti and exceptions, but still show error
`error: cannot...Hi,
I hava been trying to compile a lib using CMake 3.18 + MinGW64 + NDK r21b.
I hava tried `ANDROID_CPP_FEATURES="rtti exception"` and `ANDROID_STL_FORCE_FEATURES` to enable rtti and exceptions, but still show error
`error: cannot use 'try' with exceptions disabled`
In flags.make file generated by CMake i found`-frtti -fexceptions`flags were overwrited.
```
# CMAKE generated file: DO NOT EDIT!
# Generated by "MinGW Makefiles" Generator, CMake Version 3.18
# compile CXX with D:/code/Android/NDK/android-ndk-r21b/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
CXX_DEFINES = -DNOMINMAX
CXX_INCLUDES = -ID:\FacialAnimation\3rdparty\cereal -ID:\FacialAnimation\3rdparty\eigen-3.3.3 -ID:\FacialAnimation\3rdparty\plog -isystem D:\FacialAnimation\3rdparty\libs_android\opencv-4.1.0-ndk21-static\sdk\native\jni\include -isystem D:\FacialAnimation\3rdparty\libs_android\ncnn-20190908-armv7-ndk21\include\ncnn
CXX_FLAGS = -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -frtti -fexceptions -fPIC -fno-rtti -fno-exceptions -std=c++14
```
I remove `-fno-rtti -fno-exceptions` of CXX_FLAGS and it works. And i don't know where the last `-fno-rtti -fno-exceptions` flags are from. How to enable the rtti and exceptionshttps://gitlab.kitware.com/cmake/cmake/-/issues/20019MinGW: Drop find_library support for plain .dll files2021-11-30T10:28:08-05:00Brad KingMinGW: Drop find_library support for plain .dll filesThe `CMAKE_FIND_LIBRARY_SUFFIXES` variable used by `find_library` to consider file suffixes for linkable libraries contains `.dll` when using MinGW tools. At least at one time it was possible to link directly to a `.dll` instead of usin...The `CMAKE_FIND_LIBRARY_SUFFIXES` variable used by `find_library` to consider file suffixes for linkable libraries contains `.dll` when using MinGW tools. At least at one time it was possible to link directly to a `.dll` instead of using an import library. However, in practice packages tend to always provide the `.dll.a` import library, and it is wrong to find a MSVC-ABI `.dll` too. Maybe we should drop plain `.dll` from the default list of extensions on MinGW.3.17.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22948CMake 3.22: MINGW is false with mingw toolchains on linux2021-12-03T09:28:08-05:00Username404-59CMake 3.22: MINGW is false with mingw toolchains on linux```
if (MINGW)
message("true")
else()
message("false")
endif()
```
In this example, CMake 3.21.4 outputs "true", but CMake 3.22.0 outputs "false" instead
It may be an issue specific to cross-compilers; I haven't tested this on windo...```
if (MINGW)
message("true")
else()
message("false")
endif()
```
In this example, CMake 3.21.4 outputs "true", but CMake 3.22.0 outputs "false" instead
It may be an issue specific to cross-compilers; I haven't tested this on windows
Edit: I believe it has something to do with https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6538, though I'm not surehttps://gitlab.kitware.com/cmake/cmake/-/issues/23542MSYS/MinGW Makfiles: Hardcoded gcc/g++ does not exist on MINGW/CLANG2022-05-27T09:09:26-04:00مهدي شينون (Mehdi Chinoune)MSYS/MinGW Makfiles: Hardcoded gcc/g++ does not exist on MINGW/CLANG```CMake
cmake_minimum_required(VERSION 3.16)
project(test CXX)
add_executable(main main.cpp)
```
The clang++ compiler is in PATH:
```
$ whereis clang++
clang++: /clang64/bin/clang++.exe
```
"MSYS Makefiles"
```
$ cmake -B build/msys -G"...```CMake
cmake_minimum_required(VERSION 3.16)
project(test CXX)
add_executable(main main.cpp)
```
The clang++ compiler is in PATH:
```
$ whereis clang++
clang++: /clang64/bin/clang++.exe
```
"MSYS Makefiles"
```
$ cmake -B build/msys -G"MSYS Makefiles"
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_CXX_COMPILER:
g++.exe
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/dev/Bugs/cmake_code/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/dev/Bugs/cmake_code/build/msys/CMakeFiles/CMakeError.log".
```
"MinGW Makefiles":
```
$ cmake -B build/mingw -G"MinGW Makefiles"
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_CXX_COMPILER:
g++.exe
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/dev/Bugs/cmake_code/build/mingw/CMakeFiles/CMakeOutput.log".
See also "D:/dev/Bugs/cmake_code/build/mingw/CMakeFiles/CMakeError.log".
```
That's because the c/c++ compiler executable names are hardcoded for these generators:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Source/cmGlobalMSYSMakefileGenerator.cxx#L54
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Source/cmGlobalMinGWMakefileGenerator.cxx#L32
I think these lines should be removed to let cmake searches for C/C++ compiler like any other generator (skip https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Modules/CMakeDetermineCXXCompiler.cmake#L53 and https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Modules/CMakeDetermineCCompiler.cmake#L54)3.24.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20500MinGW: Cross compiling broken: CMake can't find windres and ignores CMAKE_RC_...2022-09-21T10:09:56-04:00Davester47MinGW: Cross compiling broken: CMake can't find windres and ignores CMAKE_RC_COMPILER.I'm trying to cross-compile glfw-3.3.2 for Windows from Debian Buster. I'm using mingw-w64 for my compiler, and all the tools have the x86_64-w64-mingw32- prefix, including windres. I'm using the version of CMake that came with my distri...I'm trying to cross-compile glfw-3.3.2 for Windows from Debian Buster. I'm using mingw-w64 for my compiler, and all the tools have the x86_64-w64-mingw32- prefix, including windres. I'm using the version of CMake that came with my distribution, which is 3.13.4. Without editing anything except at the generator screen, I get the following error:
```
[ 15%] Building RC object examples/CMakeFiles/wave.dir/glfw.rc.obj
/bin/sh: 1: windres: not found
```
At first I thought this was an error in glfw, but then I found that glfw by default sets it to what it should be, and that CMake didn't care:
```
SET(CMAKE_RC_COMPILER "x86_64-w64-mingw32-windres")
```
Even after changing CMAKE_RC_COMPILER in the menu to where it was really located, it still gave me the same error as above, and the Makefiles hadn't changed from using windres instead of x86_64-w64-mingw32-windres. I eventually that CMakeFiles/3.13.4/CMakeRCCompiler.cmake in the build directory had "windres" hardcoded into it.
CMakeFiles/3.13.4/CMakeRCCompiler.cmake:
```
set(CMAKE_RC_COMPILER "windres")
set(CMAKE_RC_COMPILER_ARG1 "")
set(CMAKE_RC_COMPILER_LOADED 1)
set(CMAKE_RC_SOURCE_FILE_EXTENSIONS rc;RC)
set(CMAKE_RC_OUTPUT_EXTENSION .obj)
set(CMAKE_RC_COMPILER_ENV_VAR "RC")
```
**To Reproduce**
Try to cross-compile any library that uses CMake with MinGW-w64 on Debian. The version that I know causes this error is CMake 3.13. I also ran into the same error when I tried to cross-compile zlib 1.2.11. CMakeFiles/3.13.4/CMakeRCCompiler.cmake had "windres" hardcoded into it in the build directory.3.18.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24061CMake fails to compile test program on Windows using generator "MinGW Makefil...2022-10-19T10:00:05-04:00Ed HartleyCMake fails to compile test program on Windows using generator "MinGW Makefiles" when installed in network location**Summary**
The "Check for working C Compiler" step fails when CMake is installed in a network location and the "MinGW Makefiles" generator is used, with the following syndrome:
```
The C compiler
"G:/MinGW/bin/gcc.exe"
is...**Summary**
The "Check for working C Compiler" step fails when CMake is installed in a network location and the "MinGW Makefiles" generator is used, with the following syndrome:
```
The C compiler
"G:/MinGW/bin/gcc.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: U:/scratch/cmake_mingw_bug/CMakeFiles/CMakeTmp
Run Build Command(s):G:/MinGW/bin/mingw32-make.exe cmTC_07339/fast && G:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTC_07339.dir\build.make CMakeFiles/cmTC_07339.dir/build
mingw32-make.exe[1]: Entering directory 'U:/scratch/cmake_mingw_bug/CMakeFiles/CMakeTmp'
process_begin: CreateProcess(NULL, \server\share\bin\cmake.exe -E cmake_echo_color --switch= --progress-dir=U:\scratch\cmake_mingw_bug\CMakeFiles\CMakeTmp\CMakeFiles --progress-num=1 "Building C object CMakeFiles/cmTC_07339.dir/testCCompiler.c.obj", ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make.exe[1]: *** [CMakeFiles\cmTC_07339.dir\build.make:83: CMakeFiles/cmTC_07339.dir/testCCompiler.c.obj] Error 2
mingw32-make.exe[1]: Leaving directory 'U:/scratch/cmake_mingw_bug/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [Makefile:139: cmTC_07339/fast] Error 2
```
**Reproduction Steps**
This appears to still be reproducible with an installation built from the ``master`` branch.
1. Install CMake on a mapped network drive on Windows.
2. Try to build a project using that installation of CMake and the ``MinGW Makefiles`` generator.
**Analysis**
It appears that CMake always resolves a canonical UNC path to the CMake executable, even if it is on a mapped drive, and the root cause appears to be related to the definition of the variable in the generated makefile:
```
CMAKE_COMMAND = \\server\share\bin\cmake.exe
```
It looks like gmake interprets the first backslash in ``\\`` as an escape character. Prepending a further escaped backslash would half solve the problem, except it also looks like there are some situations where the ``$(CMAKE_COMMAND)`` expansion is used as arguments to external tools that do not interpret the backslash as an escape character, for example, when getting CMake to re-build itself in the following excerpt, the additional escape is needed in the first line, but not the second or third.
```
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --bold --progress-dir=T:\cmake_win\winbuild\CMakeFiles --progress-num=$(CMAKE_PROGRESS_18) "Linking CXX static library libcmsys.a"
cd /d T:\cmake_win\winbuild\Source\kwsys && $(CMAKE_COMMAND) -P CMakeFiles\cmsys.dir\cmake_clean_target.cmake
cd /d T:\cmake_win\winbuild\Source\kwsys && $(CMAKE_COMMAND) -E cmake_link_script CMakeFiles\cmsys.dir\link.txt --verbose=$(VERBOSE)
```
Therefore, a practical option might be to encapsulate UNC paths in quotes when using the "MinGW Makefiles" generator for example, e.g.,
```
CMAKE_COMMAND = "\\server\share\bin\cmake.exe"
```
I was able to get CMake hosted on a network drive to rebuild another instance of CMake, by applying the following modification:
```
--- a/Source/cmOutputConverter.cxx
+++ b/Source/cmOutputConverter.cxx
@@ -527,6 +527,13 @@ bool cmOutputConverter::Shell_ArgumentNeedsQuotes(cm::string_view in,
}
}
+ /* UNC paths in MinGW Makefiles need quotes */
+ if ((flags & Shell_Flag_MinGWMake) && (flags & Shell_Flag_Make) && in.size() > 1) {
+ if (in[0] == '\\' && in[1] == '\\') {
+ return true;
+ }
+ }
+
return false;
}
```https://gitlab.kitware.com/cmake/cmake/-/issues/21509GET_RUNTIME_DEPENDENCIES does not seem to work with MinGW2022-10-20T13:56:04-04:00Bogdan BGET_RUNTIME_DEPENDENCIES does not seem to work with MinGWHi,
I am using Arch Linux with MinGW and cmake 3.19. I have a shared library and I am trying to get its runtime dependencies:
```cmake
set(CMAKE_MINGW_SYSTEM_LIBRARY_PATH \"${CMAKE_FIND_ROOT_PATH}/bin/\")")
install(CODE [[
messa...Hi,
I am using Arch Linux with MinGW and cmake 3.19. I have a shared library and I am trying to get its runtime dependencies:
```cmake
set(CMAKE_MINGW_SYSTEM_LIBRARY_PATH \"${CMAKE_FIND_ROOT_PATH}/bin/\")")
install(CODE [[
message(STATUS "Looking for deps in ${CMAKE_SYSTEM_LIBRARY_PATH};${CMAKE_MINGW_SYSTEM_LIBRARY_PATH}")
file(GET_RUNTIME_DEPENDENCIES
RESOLVED_DEPENDENCIES_VAR deps_resolved
UNRESOLVED_DEPENDENCIES_VAR deps_unresolved
LIBRARIES $<TARGET_FILE:mylib>
DIRECTORIES ${CMAKE_SYSTEM_LIBRARY_PATH} ${CMAKE_MINGW_SYSTEM_LIBRARY_PATH}
PRE_EXCLUDE_REGEXES "api-ms-*" "ext-ms-*"
POST_EXCLUDE_REGEXES ".*system32/.*\\.dll"
)
message(STATUS "Resolving runtime dependencies for $<TARGET_FILE:mylib>")
foreach(dep ${deps_resolved})
file(INSTALL ${dep} DESTINATION ${CMAKE_INSTALL_PREFIX})
endforeach()
foreach(dep ${deps_unresolved})
message(WARNING "Runtime dependency ${dep} could not be resolved.")
endforeach()
]])
```
The variable `CMAKE_MINGW_SYSTEM_LIBRARY_PATH` points to the correct path on my system `/usr/x86_64-w64-mingw32/bin`. The code does not return anything at all (no resolved, no unresolved), it just seems that it does not find anything.
The same works fine with MSVC / cmake version 3.18.20081302-MSVC_2.
I first asked on the forum [here](https://discourse.cmake.org/t/get-runtime-dependencies-does-not-seem-to-work-with-mingw/2239) and opening this issue as instructed. I will be happy to assist with any other details.
Thanks,
Bogdanhttps://gitlab.kitware.com/cmake/cmake/-/issues/23841Modules/Platform/Windows-GNU.cmake: _CMAKE_TOOLCHAIN_PREFIX on windres2022-11-28T17:52:39-05:00B. Scott MichelModules/Platform/Windows-GNU.cmake: _CMAKE_TOOLCHAIN_PREFIX on windresI just encountered this in 3.24.0 after a recent upgrade. No Cygwin or MinGW toolchain distributes a version of `windres` with the toolchain prefix prepended; Linux packages sometimes have a prepended toolchain name for cross-compiles. T...I just encountered this in 3.24.0 after a recent upgrade. No Cygwin or MinGW toolchain distributes a version of `windres` with the toolchain prefix prepended; Linux packages sometimes have a prepended toolchain name for cross-compiles. There have been proposals to do this for Windows-native, but it's never been done AFAIK.
The "solution" is to manually copy `windres` to `<toolchain prefix>-windres`, which is really suboptimal and breaks packaging badly.
This change now breaks all of my MinGW builds on Windows.3.24.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24642[Regression] Building QGIS on MSYS/MinGW with Ninja Generator with CMake 3.26.12023-03-28T08:11:18-04:00مهدي شينون (Mehdi Chinoune)[Regression] Building QGIS on MSYS/MinGW with Ninja Generator with CMake 3.26.1As I have posted in !8346, Building QGIS started failing after updating Cmake to 3.26.1.
It replaces backward slashes with nothing instead of forward slashes, I tried to revert only https://gitlab.kitware.com/cmake/cmake/-/commit/601322...As I have posted in !8346, Building QGIS started failing after updating Cmake to 3.26.1.
It replaces backward slashes with nothing instead of forward slashes, I tried to revert only https://gitlab.kitware.com/cmake/cmake/-/commit/60132272302f1 but It still failing.
for example for example C:\\msys64\\ucrt64\\lib\\libQt5Core.dll.a -> C:msys64ucrt64liblibQt5Core.dll.a
QGIS log: https://github.com/qgis/QGIS/actions/runs/4517306883/jobs/7959203173
```
[2860/10882] Linking CXX shared library output\libqgis_core.dll
FAILED: output/libqgis_core.dll src/core/libqgis_core.dll.a
cmd.exe /C "cd . && ccache C:\msys64\ucrt64\bin\c++.exe -DQWT_POLAR_VERSION=0x060200 -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -shared -o output\libqgis_core.dll -Wl,--out-implib,src\core\libqgis_core.dll.a -Wl,--major-image-version,3,--minor-image-version,31 @CMakeFiles\qgis_core.rsp && cd ."
```3.26.2Brad KingBrad King