CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-09T19:51:07-05:00https://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/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/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/12865CPack generated archives don't have correct permissions when cross compiling ...2022-10-17T16:47:35-04:00Kitware RobotCPack generated archives don't have correct permissions when cross compiling on windowsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12865). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12865). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/16809Request: Update Visual Studio generators with Linux X-platform project genera...2022-03-30T15:30:37-04:00Robert BielikRequest: Update Visual Studio generators with Linux X-platform project generationhttps://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/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/13934cannot find relink libraries at installation when cross-compiling with Ninja2021-06-17T10:01:16-04:00Kitware Robotcannot find relink libraries at installation when cross-compiling with NinjaThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13934). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13934). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13897Cross-compiling from Windows with a Linux-GCC toolchain exceeds max command l...2021-05-03T18:32:12-04:00Kitware RobotCross-compiling from Windows with a Linux-GCC toolchain exceeds max command line length during linkingThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13897). Further discussion may take place here.
---
When compiling using GCC on Windows as a non-cross-compile, CMake has code in th...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13897). Further discussion may take place here.
---
When compiling using GCC on Windows as a non-cross-compile, CMake has code in the platform files for using a response file to pass the objects to GCC's linker. When cross-compiling to a Linux toolchain, this workaround is not used. I was hitting this issue at around the 200-300 file count.
It seems that GCC supports the usage of response files across all OSes. Additionally, it seems that there are some cases that on certain Linux configurations (compiling natively) that they can run into the same issue as Windows. I believe CMake should use response files under the situation I am seeing (cross-compiling on Windows) and perhaps more universally.
I cross-compiled the GenICam GenAPI reference implementation from Windows to an ARM/Linux target. GenApi's source includes components Xerces and Xalan, both which have hundreds of files and hit this error. The error shown is an unterminated string in sh.exe because the line is truncated.
To work around this I added the following into the macro section of `Linux-GNU.cmake` (copied from the Windows version of that file):
```cmake
set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1)
set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_INCLUDES 1)
# We prefer "@" for response files but it is not supported by gcc 3.
execute_process(COMMAND ${CMAKE_${lang}_COMPILER} --version OUTPUT_VARIABLE _ver ERROR_VARIABLE _ver)
if("${_ver}" MATCHES "\\(GCC\\) 3\\.")
if("${lang}" STREQUAL "Fortran")
# The GNU Fortran compiler reports an error:
# no input files; unwilling to write output files
# when the response file is passed with "-Wl,@".
set(CMAKE_Fortran_USE_RESPONSE_FILE_FOR_OBJECTS 0)
else()
# Use "-Wl,@" to pass the response file to the linker.
set(CMAKE_${lang}_RESPONSE_FILE_LINK_FLAG "-Wl,@")
endif()
# The GNU 3.x compilers do not support response files (only linkers).
set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_INCLUDES 0)
elseif(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS)
# Use "@" to pass the response file to the front-end.
set(CMAKE_${lang}_RESPONSE_FILE_LINK_FLAG "@")
endif()
```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/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/16647FindPkgConfig: translate pkg-config target paths to host when cross-compiling2020-12-15T04:11:42-05:00David RobsonFindPkgConfig: translate pkg-config target paths to host when cross-compilingWe have a library (nanomsg in this case) which we build for ourselves if the library is not found. Therefore, we create an imported target and set the target properties. When we cross compile this on a toolchain which already has nanom...We have a library (nanomsg in this case) which we build for ourselves if the library is not found. Therefore, we create an imported target and set the target properties. When we cross compile this on a toolchain which already has nanomsg, the package points to "/usr/lib", but it's really located in "*\<sysroot\>*/usr/lib".
root@15e3ded24d03:/gateway# cmake --version
cmake version 2.8.12.2
Here are the cmake instructions generating this imported target:
```cmake
pkg_search_module(NANOMSG REQUIRED nanomsg)
set (NANOMSG_LIB_LOCATION "${NANOMSG_LIBDIR}/lib${NANOMSG_LIBRARIES}.so")
message(STATUS "NANOMSG_FOUND ${NANOMSG_FOUND}")
message(STATUS "NANOMSG_LIBRARIES ${NANOMSG_LIBRARIES}")
message(STATUS "NANOMSG_LIBRARY_DIRS ${NANOMSG_LIBRARY_DIRS}")
message(STATUS "NANOMSG_LDFLAGS ${NANOMSG_LDFLAGS}")
message(STATUS "NANOMSG_LDFLAGS_OTHER ${NANOMSG_LDFLAGS_OTHER}")
message(STATUS "NANOMSG_INCLUDE_DIRS ${NANOMSG_INCLUDE_DIRS}")
message(STATUS "NANOMSG_CFLAGS ${NANOMSG_CFLAGS}")
message(STATUS "NANOMSG_CFLAGS_OTHER ${NANOMSG_CFLAGS_OTHER}")
message(STATUS "NANOMSG VERSION: ${NANOMSG_VERSION}")
message(STATUS "NANOMSG PREFIX: ${NANOMSG_PREFIX}")
message(STATUS "NANOMSG INCLUDEDIR: ${NANOMSG_INCLUDEDIR}")
message(STATUS "NANOMSG LIBDIR: ${NANOMSG_LIBDIR}")
add_library(nanomsg SHARED IMPORTED)
set_target_properties(nanomsg PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${NANOMSG_INCLUDEDIR}"
INTERFACE_LINK_LIBRARIES "${NANOMSG_LIBRARIES}"
INTERFACE_COMPILE_OPTIONS "${NANOMSG_LDFLAGS}"
IMPORTED_LOCATION "${NANOMSG_LIB_LOCATION}"
)
```
The output from this:
```
-- NANOMSG_FOUND 1
-- NANOMSG_LIBRARIES nanomsg
-- NANOMSG_LIBRARY_DIRS
-- NANOMSG_LDFLAGS -lnanomsg
-- NANOMSG_LDFLAGS_OTHER
-- NANOMSG_INCLUDE_DIRS
-- NANOMSG_CFLAGS
-- NANOMSG_CFLAGS_OTHER
-- NANOMSG VERSION: 1.0.0
-- NANOMSG PREFIX: /usr
-- NANOMSG INCLUDEDIR: /usr/include
-- NANOMSG LIBDIR: /usr/lib
-- NANOMSG LIBRARIES: nanomsg
-- NANOMSG LDFLAGS: -lnanomsg
-- NANOMSG CFLAGS:
-- NANOMSG LOCATION: /usr/lib/libnanomsg.so
```
pkg-config output
```
root@15e3ded24d03:/gateway# pkg-config --print-variables nanomsg
exec_prefix
includedir
libdir
pcfiledir
prefix
root@15e3ded24d03:/gateway# pkg-config --variable=exec_prefix nanomsg
/usr
root@15e3ded24d03:/gateway# pkg-config --variable=includedir nanomsg
/usr/include
root@15e3ded24d03:/gateway# pkg-config --variable=libdir nanomsg
/usr/lib
root@15e3ded24d03:/gateway# pkg-config --variable=pcfiledir nanomsg
*<sysroot>*/usr/lib/pkgconfig
root@15e3ded24d03:/gateway# pkg-config --variable=prefix nanomsg
/usr
```
The make error:
```
make[2]: *** No rule to make target `/usr/lib/libnanomsg.so', needed by `core/libgateway.so'. Stop.
```
The generated `link.txt`:
> *\<sysroot_native\>*/arm-poky-linux-gnueabi-gcc -fPIC --std=c99
> -fPIC -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -pipe -march=armv7-a -mfloat-abi=hard -mfpu=neon -m
> tune=cortex-a9 --sysroot=*\<sysroot\>* -g -Wl,-O1 -Wl,--hash-style=gn
> u -Wl,--as-needed --sysroot=*\<sysroot\>* -Wl,-soname,libgatew
> ay.so -o libgateway.so CMakeFiles/gateway.dir/src/message.c.o CMakeFiles/gateway.dir/src/internal/event_system.c.o CMake
> Files/gateway.dir/src/gateway_internal.c.o CMakeFiles/gateway.dir/src/gateway.c.o CMakeFiles/gateway.dir/src/gateway_cre
> atefromjson.c.o CMakeFiles/gateway.dir/src/broker.c.o CMakeFiles/gateway.dir/src/module_loader.c.o CMakeFiles/gateway.di
> r/adapters/dynamic_library_linux.c.o CMakeFiles/gateway.dir/adapters/gb_library_linux.c.o CMakeFiles/gateway.dir/src/mod
> ule_loaders/dynamic_loader.c.o deps/libparson.a **/usr/lib/libnanomsg.so** ../../install-deps/lib/libaziotsharedutil.so -ldl
> -lm -luuid -lcurl -lssl -lcrypto -lpthread -lm -luuid -Wl,-rpath,/gateway/install-deps/lib:::::::::::::::::::::
Is there a better solution for this? I worked around this by not creating the imported target when nanomsg is found in a "standard" location, but it doesn't cover all of the possible locations a toolchain might install a library, and I don't want to add edge cases.https://gitlab.kitware.com/cmake/cmake/-/issues/16410ExternalProject: AR tool not found2020-12-04T18:43:56-05:00Paweł BylicaExternalProject: AR tool not foundWhen cross-compiling for Emscripten, the build step of an ExternalProject fails because AR tool path is unknown to it. I'm getting the error:
```
Linking CXX static library libX.a
CMAKE_AR-NOTFOUND cr libX.a source.cpp.o
```
The workar...When cross-compiling for Emscripten, the build step of an ExternalProject fails because AR tool path is unknown to it. I'm getting the error:
```
Linking CXX static library libX.a
CMAKE_AR-NOTFOUND cr libX.a source.cpp.o
```
The workaround is to add additional cmake argument to ExternlaProject_Add: `-DCMAKE_AR=${CMAKE_AR}`.
The same issue might be for the RANLIB tool as Emscripten overwrites it as well.https://gitlab.kitware.com/cmake/cmake/-/issues/16283TestBigEndian.cmake:51 (messag no suitable type found2020-09-18T14:43:37-04:00rajnishTestBigEndian.cmake:51 (messag no suitable type foundI am getting below error with cmake 3.6.1 version
with gcc tool chain 4.8 cross compiler.
Thanks
```
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - failed
-- Check size of unsig...I am getting below error with cmake 3.6.1 version
with gcc tool chain 4.8 cross compiler.
Thanks
```
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - failed
-- Check size of unsigned int
-- Check size of unsigned int - failed
-- Check size of unsigned long
-- Check size of unsigned long - failed
CMake Error at /usr/local/share/cmake-3.6/Modules/TestBigEndian.cmake:51 (messag
no suitable type found
Call Stack (most recent call first):
ConfigureChecks.cmake:279 (test_big_endian)
CMakeLists.txt:82 (include)
```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/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/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/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/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)