CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-04-23T23:43:12-04:00https://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/24301cmake creates Windows binary with UNIX like SOVERSION2023-01-24T06:01:23-05:00rhabackercmake creates Windows binary with UNIX like SOVERSIONUnder openSUSE/Leap 15.4 I cross-compiled a small C++ application for Windows and found that it is not executable like this after a transfer to a Windows system, because it takes care of the SOVERSION target property in a unix-like way b...Under openSUSE/Leap 15.4 I cross-compiled a small C++ application for Windows and found that it is not executable like this after a transfer to a Windows system, because it takes care of the SOVERSION target property in a unix-like way by appending the version to the executable name, e.g. `app.exe-<version>` and creates a symlink to this file with a name without version.
When creating a Windows application, using `app-<version>.exe` would be better here as the symlink is not usable on Windows and the binary has an incompatible extension.
How to reproduce:
--
```sh
sudo zypper ar http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_15.4/windows%3Amingw%3Awin32.repo
sudo zypper install mingw32-cross-gcc-c++ cmake p7zip-full
cmake --version
cmake version 3.25.0
mkdir ~/test
cd test
wget https://gitlab.kitware.com/cmake/cmake/uploads/4db4dafd4dde76017c3ec9fb36ff9584/cmake-test.7z
7za x cmake-test.7z
cmake -DCMAKE_SYSTEM_NAME=Windows \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw \
-DCMAKE_INSTALL_LIBDIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib \
-DBIN_INSTALL_DIR=/usr/i686-w64-mingw32/sys-root/mingw/bin \
-DINCLUDE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/include \
-DLIB_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib \
-DSHARE_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share \
-DSYSCONF_INSTALL_DIR:PATH=/usr/i686-w64-mingw32/sys-root/mingw/etc \
-DSHARE_INSTALL_PREFIX:PATH=/usr/i686-w64-mingw32/sys-root/mingw/share \
-DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_C_COMPILER=/usr/bin/i686-w64-mingw32-gcc \
-DCMAKE_CXX_COMPILER=/usr/bin/i686-w64-mingw32-g++ \
-DCMAKE_RC_COMPILER=/usr/bin/i686-w64-mingw32-windres \
-DCMAKE_FIND_ROOT_PATH=/usr/i686-w64-mingw32/sys-root/mingw \
-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY \
-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY \
-DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER \
-B build-test/ \
.
cmake --build build-test
ls -l build-test
lrwxrwxrwx 1 users users 20 9. Jan 16:51 exampleapp.exe -> exampleapp.exe-3.1.1
-rwxr-xr-x 1 users users 107722 9. Jan 16:51 exampleapp.exe-3.1.1
```
[cmake-test.7z](/uploads/4db4dafd4dde76017c3ec9fb36ff9584/cmake-test.7z)https://gitlab.kitware.com/cmake/cmake/-/issues/22678Missing -rpath-link argument for imported shared dependencies2021-10-19T18:36:44-04:00Jörg BornemannMissing -rpath-link argument for imported shared dependenciesUsed CMake version: 3.21.2 and master branch at c5b91304edaddd82992140e5b36533509c95b20f.
Consider a project with two shared libs that depend on each other:
```
# src/libs/CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(my_l...Used CMake version: 3.21.2 and master branch at c5b91304edaddd82992140e5b36533509c95b20f.
Consider a project with two shared libs that depend on each other:
```
# src/libs/CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(my_libs)
add_library(A SHARED a.cpp)
add_library(B SHARED b.cpp)
target_link_libraries(B PRIVATE A)
install(TARGETS A EXPORT A LIBRARY)
install(TARGETS B EXPORT B LIBRARY)
install(EXPORT A FILE AConfig.cmake DESTINATION lib/cmake/A)
install(EXPORT B FILE BConfig.cmake DESTINATION lib/cmake/B)
```
We cross-build this library with some embedded Linux toolchain.
The important thing is, that a sysroot is set.
Now, we try to build an application against the installed libs:
```
# src/app/CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(my_app)
find_package(B CONFIG REQUIRED)
add_executable(my_app main.cpp)
target_link_libraries(my_app PRIVATE B)
```
This fails, because of a missing `-rpath-link` argument.
The `-rpath` argument that's added is not sufficient, because the sysroot is be prepended to it internally by the linker.
See [QTBUG-86533](https://bugreports.qt.io/browse/QTBUG-86533) for a detailed explanation.
If both projects are built as part of a top-level project, the `-rpath-link` argument is correctly added.
Note that this behavior wrt `-rpath-link` can be reproduced on desktop Linux already.
Just the linking of my_app does not fail for the reason mentioned above.
I've attached an example to reproduce this issue: [cmake-rpath-link-issue.tar.gz](/uploads/edd8306f6eb1c6af949657641373726e/cmake-rpath-link-issue.tar.gz)
The example specifies an invalid `CMAKE_SYSROOT` to simulate a cross-build on Desktop Linux.
Extract the archive and run the `reproduce` script.https://gitlab.kitware.com/cmake/cmake/-/issues/21942find_library: Require static libraries (.a) from toolchain file2021-03-16T11:43:32-04:00Alexander Richardsonfind_library: Require static libraries (.a) from toolchain fileI have a cross-compilation toolchain file where I would like to enforce static linking (even if a .so exist).
I tried adding `set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")`, but this is overwritten by the `project()` command, in https://gitlab.k...I have a cross-compilation toolchain file where I would like to enforce static linking (even if a .so exist).
I tried adding `set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")`, but this is overwritten by the `project()` command, in https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.7/Modules/CMakeGenericSystem.cmake#L25
This causes problems later on when the project uses `find_package(ZLIB)` because the linker flags contain "-static"
`ld.lld: error: attempted static link of dynamic object /Users/alex/cheri/output/rootfs-riscv64-purecap/usr/lib/libz.so`
The same directory contains a libz.a that I would like to use instead.
I can obviously add another `set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")` after the `project()` command to work around this, but then I need to patch every project instead of being able to rely on the toolchain file.https://gitlab.kitware.com/cmake/cmake/-/issues/21291Crosscompiling on Windows system escapes $ORIGIN for INSTALL_RPATH2021-04-04T07:40:45-04:00Tobias WilkerCrosscompiling on Windows system escapes $ORIGIN for INSTALL_RPATHI am cross-compiling for a Linux system on my Windows machine. I need to set the RPATH property to $ORIGIN. For that I use the following code.
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "\$ORIGIN")`
What I get is \\$OR...I am cross-compiling for a Linux system on my Windows machine. I need to set the RPATH property to $ORIGIN. For that I use the following code.
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "\$ORIGIN")`
What I get is \\$ORIGIN.
![RPATH](/uploads/973e641145b1ab891f15d22eebabbe41/RPATH.PNG)
I also tried different ways to escape the $ sign
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "$ORIGIN")` -> \\$ORIGIN
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH $ORIGIN)` -> \\$ORIGIN
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH \$ORIGIN)` -> \\$ORIGIN
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "\\\$ORIGIN")` -> \\\\\\$ORIGIN
When I cross-compile the same project using a Linux machine, than it works. Meaning "\\$ORIGIN" -> $ORIGIN.https://gitlab.kitware.com/cmake/cmake/-/issues/20956iOS: MACOSX_BUNDLE property incorrect when using CMAKE_SYSTEM_NAME=iOS2020-08-25T05:53:13-04:00ChristopheiOS: MACOSX_BUNDLE property incorrect when using CMAKE_SYSTEM_NAME=iOSThe target property MACOSX_BUNDLE returns an incorrect value when used with cross compilation to iOS.
Take the following very simple CMake file
```cmake
cmake_minimum_required(VERSION 3.17.3)
project(test LANGUAGES C CXX VERSION 1.0.0....The target property MACOSX_BUNDLE returns an incorrect value when used with cross compilation to iOS.
Take the following very simple CMake file
```cmake
cmake_minimum_required(VERSION 3.17.3)
project(test LANGUAGES C CXX VERSION 1.0.0.1)
add_library(${PROJECT_NAME}_lib STATIC ${PROJECT_NAME}.cpp)
get_target_property(isBundle ${PROJECT_NAME}_lib MACOSX_BUNDLE)
message("IsBundle: ${PROJECT_NAME}_lib -> ${isBundle}")
```
### No cross-compilation
* Generate the solution like this: `cmake -H. -B_build -GXcode`
* MAXOSX_BUNDLE is not defined
### With iOS cross-compilation
* Generate the solution with iOS cross-compilation: `cmake -H. -B_build -GXcode -DCMAKE_SYSTEM_NAME=iOS`
* MAXOSX_BUNDLE is always defined to `ON` for static libraries, dynamic libraries, executables
I don't know if this is a cross compilation general issue or just for iOS.
Tested with CMake 3.17.3 on macOS (obviously :)).https://gitlab.kitware.com/cmake/cmake/-/issues/20753GET_RUNTIME_DEPENDENCIES broken for cross-compiling2024-03-09T19:51:07-05:00Frank RichterGET_RUNTIME_DEPENDENCIES broken for cross-compilingI'm cross-compiling from Linux to Windows and I noticed a number of issues with `file(GET_RUNTIME_DEPENDENCIES)` in this scenario. The "visible" result is that it doesn't produce any dependencies (neither resolved nor unresolved!), even ...I'm cross-compiling from Linux to Windows and I noticed a number of issues with `file(GET_RUNTIME_DEPENDENCIES)` in this scenario. The "visible" result is that it doesn't produce any dependencies (neither resolved nor unresolved!), even though the tools are there.
1. I noticed the implementation uses `CMAKE_HOST_SYSTEM_NAME` to select the platform. In my scenario the host system is "`Linux`", meaning the chosen platform is "`linux+elf`", even though "`windows+pe`" would be correct. Workaround: manually set `CMAKE_GET_RUNTIME_DEPENDENCIES_PLATFORM`.
2. The wrong '`objdump`' was used, the 'native' `/bin/objdump` instead of the cross-building `objdump`. Workaround: manually setting `CMAKE_GET_RUNTIME_DEPENDENCIES_COMMAND`, `CMAKE_GET_RUNTIME_DEPENDENCIES_TOOL`. (But I believe this is fixed in master now.)
3. The interpretation of the objdump output expects a CR at the end of a line. This is not present on Linux. Workaround: employing a wrapper script that pipes the objdump output through unix2dos.
4. Library name case mismatches. Yeah, this is tricky. In my case I want Qt DLLs, and for them returning the "resolved" dependencies unchanged would be fine, but that's not a general case. Workaround: Attempting a "case-insensitive" search for the library name (i.e., scanning directories and comparing each file name) and recursively feeding those to `file(GET_RUNTIME_DEPENDENCIES)` again, all with CMake scripting. Kludgy, but works for now.https://gitlab.kitware.com/cmake/cmake/-/issues/20404Ninja: Broken build.ninja when build tree is a Windows drive root2020-03-03T06:56:59-05:00Andrei JianuNinja: Broken build.ninja when build tree is a Windows drive rootHi all,
**Description**:
In case of generating the ninja build solution in the root directory of any disk, CMake is adding a `$` before `:` or ` ` (space)[CMakeNinjaVS.zip](/uploads/fa9bfb4486c601eaad7dc279b278a934/CMakeNinjaVS.zip).
...Hi all,
**Description**:
In case of generating the ninja build solution in the root directory of any disk, CMake is adding a `$` before `:` or ` ` (space)[CMakeNinjaVS.zip](/uploads/fa9bfb4486c601eaad7dc279b278a934/CMakeNinjaVS.zip).
**Ninja build exmaple**
```
...
#############################################
# Make the all target the default.
default all
#############################################
# Re-run CMake if any of its inputs changed.
build build.ninja: RERUN_CMAKE | C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompiler.cmake.in C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompilerABI.c ...
#############################################
# A missing CMake input file is not an error.
build C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompiler.cmake.in C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompilerABI.c C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCInformation.cmake ...
...
```
**Environment**
CMake: 3.16.4
Ninja: 1.10.0
Windows: Windows 10 Pro 1909 (OS build: 18363.693)
**How to reproduce**
Attached you have an zip with a small test project that creates a virtual drive, W:, and generate the ninja project and tries to build it.
It uses Visual Studio for it and it is necessary to have vswhere.exe in your environment path as is using to find the Visual Studio installation path.
PS: This has been reported to ninja issue board also
https://github.com/ninja-build/ninja/issues/1747https://gitlab.kitware.com/cmake/cmake/-/issues/19857CUDA and CMAKE_SYSROOT: not picking up libraries from the sysroot2019-11-18T03:47:29-05:00Carlos GalvezCUDA and CMAKE_SYSROOT: not picking up libraries from the sysrootHi,
We have a cross-compilation toolchain (Linux, aarch64) that uses CUDA. Following the recommended pattern for Linux toolchains, we set the `CMAKE_SYSROOT` to point to the `targetfs` containing the `/include` and `/lib` from the tar...Hi,
We have a cross-compilation toolchain (Linux, aarch64) that uses CUDA. Following the recommended pattern for Linux toolchains, we set the `CMAKE_SYSROOT` to point to the `targetfs` containing the `/include` and `/lib` from the target platform.
For C++ code this works fine and it uses the libraries from the `targetfs`. However it does not work for CUDA libraries, because CMake is appending `-L /usr/local/cuda/targets/aarch64-linux/lib` instead of `-L <targetfs>/usr/local/cuda/targets/aarch64-linux/lib`. I.e the `CMAKE_CUDA_HOST_IMPLICIT_LINK_DIRECTORIES` is taken from the host filesystem instead of from the targetfs set by `CMAKE_SYSROOT`.
Therefore we need ugly symlinks from `targetfs` to `/usr/local` to make this work. Is there a flag we can use to tell CMake to use the CUDA libraries that it can find inside the `targetfs` specified by `CMAKE_SYSROOT`?
Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/19129cross-compiling: compilation database use wrong command2019-04-22T01:52:52-04:00suyucross-compiling: compilation database use wrong commandI have project with CMake, it can build successfully.
But when I generate compilation database by `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON`,
it use wrong command int the file
for example
All the source file in contracts use wrong command.
`...I have project with CMake, it can build successfully.
But when I generate compilation database by `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON`,
it use wrong command int the file
for example
All the source file in contracts use wrong command.
```json
{
"directory": "/root/workspace/eos4/build/contracts/eosio.system",
"command": "/usr/bin/clang++-4.0 -I/root/workspace/eos4/contracts/eosio.system/.. -Wall -Wno-invalid-partial-specialization -O3 -DNDEBUG -std=gnu++14 -o CMakeFiles/eosio.system.tmp.dir/eosio.system.cpp.o -c /root/workspace/eos4/contracts/eosio.system/eosio.system.cpp",
"file": "/root/workspace/eos4/contracts/eosio.system/eosio.system.cpp"
},
```
the right command should be :
```
/root/opt/wasm/bin/clang -emit-llvm -O3 --std=c++14 --target=wasm32 -ffreestanding -nostdlib -nostdlibinc -fno-threadsafe-statics -fno-rtti -fno-exceptions -c /root/workspace/eos4/contracts/eosio.system/eosio.system.cpp -o eosio.system.cpp.bc -Weverything -Wno-c++98-compat -Wno-old-style-cast -Wno-vla -Wno-vla-extension -Wno-c++98-compat-pedantic -Wno-missing-prototypes -Wno-missing-variable-declarations -Wno-packed -Wno-padded -Wno-c99-extensions -Wno-documentation-unknown-command -I /root/workspace/eos4/contracts -I /root/workspace/eos4/externals/magic_get/include -isystem /root/workspace/eos4/contracts/libc++/upstream/include -isystem /root/workspace/eos4/contracts/musl/upstream/include -isystem /root/opt/boost/include -isystem /root/workspace/eos4/contracts/libc++/upstream/include -isystem /root/workspace/eos4/contracts/musl/upstream/include -isystem /root/opt/boost/include
```
the project
https://github.com/EOSIO/eos
Thanks.
[clangd.tar.gz](/uploads/f907663bec3f345a071e4b0c53325a25/clangd.tar.gz)https://gitlab.kitware.com/cmake/cmake/-/issues/19122CheckTypeSize does not work with iOS cross-compilation2019-10-25T03:53:45-04:00Ludovic BaillyCheckTypeSize does not work with iOS cross-compilationHi ! I may have identified a problem with iOS cross-compilation. Thank you in advance for the support, I'm available if you need more details.
# Issue
I'm trying to compile a library with iOS cross-compilation. I'm following the [code e...Hi ! I may have identified a problem with iOS cross-compilation. Thank you in advance for the support, I'm available if you need more details.
# Issue
I'm trying to compile a library with iOS cross-compilation. I'm following the [code example](https://cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html#cross-compiling-for-ios-tvos-or-watchos) from CMake 3.14.1 documentation. CMake module `CheckTypeSize` doesn't set type sizes when calling `check_type_size`. Native compilation on MacOS doesn't cause any problem.
This may be due to the `CheckTypeSize` module not finding the following headers :
* sys/types.h
* stdint.h
* stddef.h
You will find [here](https://github.com/Ludobaka/CMakeCheckTypeSizeIOSTest) a simple repository containing a CMakeLists.txt and a toolchain file showing the problem.
# Environment
* MacOSX Mojave 10.14
* XCode 10.1, with xcode-select installed
* CMake 3.14.1
* Using either command line for setting CMake cross-compilation variables or a toolchain file
I've tried to configure the project with and without the following CMake variables :
* Xcode generator
* `CMAKE_OSX_SYSROOT` set to `/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk`
# Logs
Native MacOS CMake configuration output :
[nativeConfigure.log](/uploads/388ff1679a27db53c553cff6a561f8cc/nativeConfigure.log)
iOS toolchain CMake configuration output
[toolchainConfigure.log](/uploads/76d0e473d5e538595dd2f103f1b122a2/toolchainConfigure.log)Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/18974Check<LANG>SourceRuns: Failed cross-compilation case can return wrong result2019-02-25T07:16:42-05:00Craig ScottCheck<LANG>SourceRuns: Failed cross-compilation case can return wrong resultIn the various `Check<LANG>SourceRuns` modules, the `check_<lang>_source_runs()` implementations all have a code block like the following:
```cmake
if("${${VAR}_EXITCODE}" EQUAL 0)
set(${VAR} 1 CACHE INTERNAL "Test ${VAR}"...In the various `Check<LANG>SourceRuns` modules, the `check_<lang>_source_runs()` implementations all have a code block like the following:
```cmake
if("${${VAR}_EXITCODE}" EQUAL 0)
set(${VAR} 1 CACHE INTERNAL "Test ${VAR}")
# ... Other logic for successful attempt
else()
if(CMAKE_CROSSCOMPILING AND "${${VAR}_EXITCODE}" MATCHES "FAILED_TO_RUN")
set(${VAR} "${${VAR}_EXITCODE}")
else()
set(${VAR} "" CACHE INTERNAL "Test ${VAR}")
endif()
# ... Other logic for failed attempt
endif()
```
In the above, `${VAR}` is the variable that is meant to hold the result of the check. The documentation of these modules all have wording like the following:
```
If the ``<code>`` could be built and run
successfully, the internal cache variable specified by ``<resultVar>`` will
be set to 1, otherwise it will be set to an value that evaluates to boolean
false (e.g. an empty string or an error message).
```
While the code and the documentation are consistent with each other, the documentation contradicts itself. An error message that matches `FAILED_TO_RUN` will evaluate to boolean true, not false. I suspect the expected/intended behavior is that the result variable would hold a false value rather than an error message if the run attempt failed.
The implementations for all three supported languages (C, C++, Fortran) have this problem.https://gitlab.kitware.com/cmake/cmake/-/issues/18285find_library/cross-compile: does not find libs without filename extension2018-08-28T05:53:04-04:00Hannes Groblerfind_library/cross-compile: does not find libs without filename extensionHi there,
I am cross compiling from Windows to QNX with qcc (modified GCC compiler) and CMake (>= 3.11.0). The compiled code depends on Boost. Additionally I am using Conan (https://conan.io) as dependency manager that generates a Findbo...Hi there,
I am cross compiling from Windows to QNX with qcc (modified GCC compiler) and CMake (>= 3.11.0). The compiled code depends on Boost. Additionally I am using Conan (https://conan.io) as dependency manager that generates a Findboost.cmake file to utilize find_library(boost ...). The generated Find-file does specify the boost libraries by their plain names (e.g. boost_system, boost_chrono, ...).
problem
-------
When I build from Windows for Windows (native build; Visual Studio compiler "VS2015") then the real library filename is "boost_system.lib". find_library finds the files, this works as expected.
When I build from Windows for QNX (cross build; qcc) then the real library filename is "boost_system.so". find_library does not find the files.
investigation
-------------
The calling code looks like this (copy-paste):
```
find_package (boost 1.67.0 REQUIRED COMPONENTS system thread date_time chrono atomic log filesystem)
```
This results in console output
> -- Library boost_system not found in package, might be system one
.
The line can be found at Findboost.cmake line 38 (see attachment).
While compiling for QNX I have checked the CMAKE_FIND_LIBRARY_SUFFIXES variable while building and it says ".so;.a" as expected. So in general find_library should find the requested library "boost_atomic".
To support the problem tracking I have attached the generated Find-file.
Best regards
[Findboost.cmake](/uploads/8930605428f65c9750bf123fa088f31a/Findboost.cmake)https://gitlab.kitware.com/cmake/cmake/-/issues/17805How to let ios and macos targets in one project when generate Xcode2019-10-14T10:26:52-04:00ledaHow to let ios and macos targets in one project when generate XcodeXcode support this, but when cmake generate project every time, I have to choose ios or macos platform, can't both. is it impossible to make both in one project? How to do that. for I can't find solution in docs or google, so I came here.Xcode support this, but when cmake generate project every time, I have to choose ios or macos platform, can't both. is it impossible to make both in one project? How to do that. for I can't find solution in docs or google, so I came here.https://gitlab.kitware.com/cmake/cmake/-/issues/17718OSX Cross Compile Errors2018-02-08T11:06:49-05:00RiemanZetaOSX Cross Compile ErrorsI was working on a project that utilized a set of cross compilers and cmake. I was on OSX and I kept getting the really annoying error "no entry symbol for arch_path_first." This happens because Darwin.cmake in the cmake source automati...I was working on a project that utilized a set of cross compilers and cmake. I was on OSX and I kept getting the really annoying error "no entry symbol for arch_path_first." This happens because Darwin.cmake in the cmake source automatically adds the compiler flag: "-search_path_first." This is a standard OSX Clang flag but it does not exist for gcc. As such it will interpret "-search_path_first" as "-se=arch_path_first." If I remember correctly "-s" is equivalent to "--strip-symbols." My solution was to compile a cmake where that didn't have "-search_path_first." Essentially cmake assumed that I was compiling with clang so is there a way to add a flag so the cmake knows not to assume that?https://gitlab.kitware.com/cmake/cmake/-/issues/17643GetPrerequisites.cmake: include /usr/lib/gcc/$CARCH/$GCC_VER/ to library sear...2018-04-16T09:45:17-04:00hanetzerGetPrerequisites.cmake: include /usr/lib/gcc/$CARCH/$GCC_VER/ to library search path.currently the various macros/commands/whatever in GetPrerequisites.cmake do not
check this directory for libraries/dlls/etc which could be useful for projects
which bundle required libraries into binary dists (say, mingw-w64 built projec...currently the various macros/commands/whatever in GetPrerequisites.cmake do not
check this directory for libraries/dlls/etc which could be useful for projects
which bundle required libraries into binary dists (say, mingw-w64 built projects).https://gitlab.kitware.com/cmake/cmake/-/issues/17354How to remove `-install_name` options for mingw on mac OSX2017-10-16T13:01:16-04:00Leen GuiHow to remove `-install_name` options for mingw on mac OSXI installed the [bwapi][1] via wine on Mac OSX. And I try to cross-compile the ExampleAIModule of bwapi with CMake and MinGW on Mac OSX. The ExampleAIModule is actually a VS2017 project, I wrote a CMakeLists.txt, ran `cmake CMakeLists.tx...I installed the [bwapi][1] via wine on Mac OSX. And I try to cross-compile the ExampleAIModule of bwapi with CMake and MinGW on Mac OSX. The ExampleAIModule is actually a VS2017 project, I wrote a CMakeLists.txt, ran `cmake CMakeLists.txt && make VERBOSE=1` got some errors. `i686-w64-mingw32-g++` does not support `-install_name`, but CMake added it.
The folder structure:
BWAPI/ExampleAIModule/CMakeLists.txt
BWAPI/ExampleAIModule/Source/*.cpp *.h
BWAPI/include/*.h
BWAPI/lib/BWAPI.lib
BWAPI/lib/BWAPIClient.lib
`make` got errors:
Linking CXX shared library libExampleAIModule.dylib
/usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_link_script CMakeFiles/ExampleAIModule.dir/link.txt --verbose=1
i686-w64-mingw32-g++ -std=c++11 -O3 -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -o libExampleAIModule.dylib -install_name @rpath/libExampleAIModule.dylib CMakeFiles/ExampleAIModule.dir/Source/Dll.cpp.o CMakeFiles/ExampleAIModule.dir/Source/ExampleAIModule.cpp.o -L/.wine/drive_c/Starcraft/BWAPI/ExampleAIModule/../lib
i686-w64-mingw32-g++: error: rpath/libExampleAIModule.dylib: No such file or directory
i686-w64-mingw32-g++: error: unrecognized command line option ‘-install_name’
make[2]: *** [libExampleAIModule.dylib] Error 1
make[1]: *** [CMakeFiles/ExampleAIModule.dir/all] Error 2
CMakeLists.txt
cmake_minimum_required(VERSION 3.0.0 FATAL_ERROR)
set(PROJECT_NAME ExampleAIModule)
set(CPP_DIR_1 Source)
set(HEADER_DIR_1 Source)
project(${PROJECT_NAME} CXX)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
include_directories(../include)
link_directories(../lib)
file(GLOB SRC_FILES
${CPP_DIR_1}/*.cpp
${HEADER_DIR_1}/*.h
)
add_library(${PROJECT_NAME} SHARED
${SRC_FILES}
)
[1]: https://github.com/bwapi/bwapi/releases/download/v4.1.2/BWAPI_412_Setup.exehttps://gitlab.kitware.com/cmake/cmake/-/issues/17228WIX Generator not available under Linux2022-12-08T12:45:37-05:00Michele AdduciWIX Generator not available under LinuxThe WIX Generator for CPack could be made available in Linux as well, as long as wix binaries can run under mono (the 3.11 works with mono v4.6+)
For cross-platform environments (e.g., Travis-CI), building MSI files under Linux is not s...The WIX Generator for CPack could be made available in Linux as well, as long as wix binaries can run under mono (the 3.11 works with mono v4.6+)
For cross-platform environments (e.g., Travis-CI), building MSI files under Linux is not so uncommonhttps://gitlab.kitware.com/cmake/cmake/-/issues/17164FindwxWidgets should allow to specify which wx-config should be used.2018-11-17T21:13:13-05:00Wolfgang DautermannFindwxWidgets should allow to specify which wx-config should be used.Hi,
When crosscompiling for Windows on a Linux host, I first crosscompile wxWidgets (with externalproject_add), and afterwards I want to use this build.
This is currently not possible - for the Windows case I can set wxWidgets_ROOT_DIR...Hi,
When crosscompiling for Windows on a Linux host, I first crosscompile wxWidgets (with externalproject_add), and afterwards I want to use this build.
This is currently not possible - for the Windows case I can set wxWidgets_ROOT_DIR, but I can not specify *which* wx-config should be used in the Unix case (and crosscompiling counts as unix case). The path attached allows that, so that one could do:
set(wxWidgets_CONFIG_EXECUTABLE "${CMAKE_BINARY_DIR}/wxroot/bin/wx-config")
find_package(wxWidgets COMPONENTS core base REQUIRED)
(Note: The check, if the libraries are there, did not work, I did comment it out).[gitdiff.txt](/uploads/b79b4ec45e2fcfe92456dd3118ad1baf/gitdiff.txt)
Another note: Such a feature would probably be useful for other modules which use a ....-config command (eg. libSDL, ncurses, ...).
Best regards, Wolfganghttps://gitlab.kitware.com/cmake/cmake/-/issues/17049Crosscompiling with Clang is cumbersome2017-07-10T09:34:20-04:00nolangeCrosscompiling with Clang is cumbersomeHello,
there are several drawbacks when compiling with clang using a secondary toolchain like gcc.
There is an issue with having a separate Toolchain path, the clang/llvm path contains the compiler and several tools, while atleast the l...Hello,
there are several drawbacks when compiling with clang using a secondary toolchain like gcc.
There is an issue with having a separate Toolchain path, the clang/llvm path contains the compiler and several tools, while atleast the linker (via gcc) should be from the secondary path.
A naive toolchain fail will result in AR missing, see the attached project (a link to a crosscompiler is attached below).
See the toolchain file that is necessary to set all the variables and whether they should be picked from primary or secondary toolchain.
Also the llvm tools should be searched with and without the ${_CMAKE_TOOLCHAIN_PREFIX}.
For Cmake 3.9 the new COMPILER_RANLIB and COMPILER_AR variables have a similar issue and I attached a patch. LTO still does not work in this configuration.
There are alot of issues (see adding all those include paths, and clangs option "--gcc-toolchain" being pretty much useless), but IMHO CMake should atleast deal with finding the correct programs.
[crosscompile_clang.tar.xz](/uploads/61421b66aece199d09cf90029fc64bc6/crosscompile_clang.tar.xz)
[ARM Crosscompiler](https://developer.arm.com/open-source/gnu-toolchain/gnu-rm)
[findclangbinutils.patch](/uploads/39fc21005c745cfd92f439a5aa3de9c7/findclangbinutils.patch)