CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-07-07T10:33:11-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16943libelf RPATH parsing / install time substitution on Windows2017-07-07T10:33:11-04:00Nils Gladitzlibelf RPATH parsing / install time substitution on WindowsAssuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a ...Assuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a cross-compile setup targeting Linux.https://gitlab.kitware.com/cmake/cmake/-/issues/16919Do not emit -isystem for INSTALL_INCLUDE_PATH2018-08-30T11:11:54-04:00Demi Marie ObenourDo not emit -isystem for INSTALL_INCLUDE_PATHWhen running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilat...When running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilation to fail with:
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ext/string_conversions.h:41:0,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/basic_string.h:6157,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/string:52,
from /usr/x86_64-w64-mingw32/sys-oot/mingw/include/boost/test/utils/basic_cstring/bcs_char_traits.hpp:25,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/utils/basic_cstring/basic_cstring.hpp:21,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/detail/global_typedef.hpp:15,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tree/observer.hpp:17,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test_log.hpp:18,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tools/old/impl.hpp:19,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/test_tools.hpp:46,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test.hpp:18,
from /home/dobenour/repos/SlipRock/src/test.cpp:16:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
The culprit is that CMake generates `-isystem` flags pointing to `INCLUDE_INSTALL_DIR`, when it should use plain `-I`.
Tested with version 3.8.1 from Fedora. There was a [GCC bug] about this behavior on GCC’s part, which was closed as WONTFIX.
[GCC bug]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129https://gitlab.kitware.com/cmake/cmake/-/issues/16909CMAKE_SYSTEM_PROCESSOR is overwritten2017-05-22T09:52:46-04:00DiederickCMAKE_SYSTEM_PROCESSOR is overwrittenI'm trying to use cmake with different toolchain files to compile a library on Mac OS for armv7, armv7s, i386 and x86_64. Using toolchain files works fine, except I have to link with different libraries/frameworks based on the architectu...I'm trying to use cmake with different toolchain files to compile a library on Mac OS for armv7, armv7s, i386 and x86_64. Using toolchain files works fine, except I have to link with different libraries/frameworks based on the architecture/build. I was thinking that using CMAKE_SYSTEM_PROCESSOR was the right choice but I'm not entirely sure anymore.
When I set the CMAKE_SYSTEM_PROCESSOR in my toolchain file it's always reset to `x86_64` in my CMakeLists.txt (and external projects). I've tried using CACHED and non-cached variables. I've created a repository that can be used to reproduce the issue: https://github.com/roxlu/cmake_multi_arch
But besides this issue, I'm not sure how to handle building for the iOS simulator. When building for the iOS simulator one uses x86_64 (so CMAKE_SYSTEM_PROCESSOR would be x86_64) but I would still need to link with different libraries which are only available for iOS. In this case checking for x86_64 wouldn't be enough. Are there other options?https://gitlab.kitware.com/cmake/cmake/-/issues/16860CMAKE_C_SIZEOF_DATA_PTR is wrong when I build project on msvc2015-tegra-nsight2017-05-16T09:33:22-04:00mcleeCMAKE_C_SIZEOF_DATA_PTR is wrong when I build project on msvc2015-tegra-nsight`CMAKE_C_SIZEOF_DATA_PTR` is 4 when I select architecture `arm64-v8a`.
IDE: msvc2015
Generator: android tegra-nsight
architecture: arm64-v8a
the toolchain file setting:
```cmake
SET(CMAKE_SYSTEM_NAME Android)
SET...`CMAKE_C_SIZEOF_DATA_PTR` is 4 when I select architecture `arm64-v8a`.
IDE: msvc2015
Generator: android tegra-nsight
architecture: arm64-v8a
the toolchain file setting:
```cmake
SET(CMAKE_SYSTEM_NAME Android)
SET(CMAKE_ANDROID_NDK "path to android-ndk-r12b")
SET(CMAKE_ANDROID_ARCH "arm64-v8a")
SET(CMAKE_ANDROID_API "21")
SET(CMAKE_ANDROID_STL_TYPE "gnustl_static")
```
I have been checked `CMakeDetermineCompilerABI_C.bin`, this really contains string `INFO:sizeof_dptr[04]`
And I can run this project well on device (Google Pixel Tablet C)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/16724find_package( HDF5 ) doesn't respect CMAKE_FIND_ROOT_PATH_MODE_PACKAGE2017-10-13T13:17:55-04:00mattgruenkefind_package( HDF5 ) doesn't respect CMAKE_FIND_ROOT_PATH_MODE_PACKAGEWhile trying to cross-compile flann-1.8.4 for Android, I've encountered the following quagmire:
* Flann uses find_package( HDF5 ), but it's not required & I don't have it on the target system.
* This finds the package installed on the...While trying to cross-compile flann-1.8.4 for Android, I've encountered the following quagmire:
* Flann uses find_package( HDF5 ), but it's not required & I don't have it on the target system.
* This finds the package installed on the host, unless CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is set to ONLY (no matter what CMAKE_FIND_ROOT_PATH_MODE_PACKAGE says).
* However, when I set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to ONLY, CMake no longer finds the NDK's ar program (static linker).
* Even if I explicitly set CMAKE_AR, its value isn't respected, and the static linking command ends up as "".
It seems to me like there's one or two bugs, here. First, find_package() should respect CMAKE_FIND_ROOT_PATH_MODE_PACKAGE and be unaffected by CMAKE_FIND_ROOT_PATH_MODE_PROGRAM. That much seems clear.
Secondly, I don't understand why CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is breaking CMake's ability to find ar, not least because ar is installed in one of the directories listed in my CMAKE_FIND_ROOT_PATH. I double & triple-checked all my path strings, to make sure it's not just a typo somewhere. I'll reproduce & file this as a separate bug.
Attached is the output of CMake finding HDF5 on the host system, then trying to use it during cross-compilation. Toolchain file also included. Though I think the issue is probably a bug in `share/cmake-3.7/Modules/FindHDF5.cmake`, rather than anything specific to flann, it can be obtained from http://www.cs.ubc.ca/research/flann/
[toolchain_android.cmake](/uploads/e7f23ecc41cb9de3218510ee2441cc82/toolchain_android.cmake)
[flann-1.8.4_build.log](/uploads/161aae033dc75b783c574f73e9c4ae84/flann-1.8.4_build.log)https://gitlab.kitware.com/cmake/cmake/-/issues/16683CMake Can't be used for AIX with GNU ld (cross-compilation)2017-10-13T13:17:55-04:00Byoungchan LeeCMake Can't be used for AIX with GNU ld (cross-compilation)I'm trying to setup AIX cross-compile tool using GCC (4.8) and GNU Binutils (2.24) on Linux Host.
When I Use CMake 2.8,7 (Ubuntu 12.04), it can be used for compile C++ programs without any problems.
However, when I use CMake 3.5.1 (U...I'm trying to setup AIX cross-compile tool using GCC (4.8) and GNU Binutils (2.24) on Linux Host.
When I Use CMake 2.8,7 (Ubuntu 12.04), it can be used for compile C++ programs without any problems.
However, when I use CMake 3.5.1 (Ubuntu 16.04), it can't link C++ Programs.
```
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_49385.dir/link.txt
--verbose=1
/home/leebc/toolchain/aix/gcc4.8/bin/powerpc-ibm-aix5.3.0.0-g++
-Wl,-bnoipath -Wl,-brtl CMakeFiles/cmTC_49385.dir/testCXXCompiler.cxx.o -o
cmTC_49385 -Wl,-blibpath:/usr/lib:/lib
/home/leebc/toolchain/aix/gcc4.8/lib/gcc/powerpc-ibm-aix5.3.0.0/4.8.2/../../../../powerpc-ibm-aix5.3.0.0/bin/ld:
target noipath not found
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_49385.dir/build.make:97: recipe for target 'cmTC_49385'
failed
make[1]: *** [cmTC_49385] Error 1
make[1]: Leaving directory
'/home/leebc/myproj/CMakeFiles/CMakeTmp'
```
If I rollback this [commit](https://github.com/Kitware/CMake/commit/767a7ad9dac20d252e71941b6cf03f123c7c37fc), it works fine. Seems like `bnoipath` flag works only for AIX ld, which cannot be used on cross-compilation.https://gitlab.kitware.com/cmake/cmake/-/issues/16659Problem with finding wxWidgets install on windows2017-10-13T13:17:55-04:00deltProblem with finding wxWidgets install on windowsThe current version of the script file 'Modules/FindwxWidgets.cmake' has an error which prevents it from successfully detecting a wxWidgets installation when using either MXE or MSYS2 to cross-compile an app for windows. I was able to wo...The current version of the script file 'Modules/FindwxWidgets.cmake' has an error which prevents it from successfully detecting a wxWidgets installation when using either MXE or MSYS2 to cross-compile an app for windows. I was able to work around this problem by commenting out the following block around line 850-900. I'm pretty sure however this quick hack breaks some features i don't use, and/or might cause problems for other users.
```
# Check if a specfic version was requested by find_package().
# if(wxWidgets_FOUND)
# find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} NO_DEFAULT_PATH)
# dbg_msg("_filename: ${_filename}")
#
# if(NOT _filename)
# message(FATAL_ERROR "wxWidgets wx/version.h file not found in ${wxWidgets_INCLUDE_DIRS}.")
# endif()
#
# file(READ ${_filename} _wx_version_h)
#
# string(REGEX REPLACE "^(.*\n)?#define +wxMAJOR_VERSION +([0-9]+).*"
# "\\2" wxWidgets_VERSION_MAJOR "${_wx_version_h}" )
# string(REGEX REPLACE "^(.*\n)?#define +wxMINOR_VERSION +([0-9]+).*"
# "\\2" wxWidgets_VERSION_MINOR "${_wx_version_h}" )
# string(REGEX REPLACE "^(.*\n)?#define +wxRELEASE_NUMBER +([0-9]+).*"
# "\\2" wxWidgets_VERSION_PATCH "${_wx_version_h}" )
# set(wxWidgets_VERSION_STRING
# "${wxWidgets_VERSION_MAJOR}.${wxWidgets_VERSION_MINOR}.${wxWidgets_VERSION_PATCH}" )
# dbg_msg("wxWidgets_VERSION_STRING: ${wxWidgets_VERSION_STRING}")
# endif()
```
Output from the 'cmake' command when attempting to create a Makefile:
```
[pts/18][user@phobos]:/net/deimos/home/user/acu/src/build-mxe$ i686-w64-mingw32.static-cmake -DwxWidgets_CONFIG_EXECUTABLE=/usr/lib/mxe/bin/wx-config ..
== Using MXE wrapper: /usr/lib/mxe/usr/bin/i686-w64-mingw32.static-cmake
== Using MXE toolchain: /usr/lib/mxe/usr/i686-w64-mingw32.static/share/cmake/mxe-conf.cmake
== Using MXE runresult: /usr/lib/mxe/usr/share/cmake/modules/TryRunResults.cmake
loading initial cache file /usr/lib/mxe/usr/share/cmake/modules/TryRunResults.cmake
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/lib/mxe/usr/bin/i686-w64-mingw32.static-gcc
-- Check for working C compiler: /usr/lib/mxe/usr/bin/i686-w64-mingw32.static-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/mxe/usr/bin/i686-w64-mingw32.static-g++
-- Check for working CXX compiler: /usr/lib/mxe/usr/bin/i686-w64-mingw32.static-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(166): wxWidgets_FIND_COMPONENTS : net;adv;core;base
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(166): wxWidgets_SELECT_OPTIONS=--debug=no;--static=yes;--unicode=yes;--universal=no
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(170): wxWidgets_CXX_FLAGS=-I/usr/lib/mxe/lib/wx/include/i686-w64-mingw32.static-msw-unicode-static-3.1;-I/usr/lib/mxe/include/wx-3.1;-D_FILE_OFFSET_BITS=64;-DwxDEBUG_LEVEL=0;-D__WXMSW__;-mthreads
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(170): wxWidgets_DEFINITIONS=_FILE_OFFSET_BITS=64;wxDEBUG_LEVEL=0;__WXMSW__
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(170): wxWidgets_INCLUDE_DIRS=/usr/lib/mxe/lib/wx/include/i686-w64-mingw32.static-msw-unicode-static-3.1;/usr/lib/mxe/include/wx-3.1
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(170): wxWidgets_CXX_FLAGS=-mthreads
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(170): wxWidgets_LIBRARIES=-L/usr/lib/mxe/lib;;;-Wl,--subsystem,windows;-mwindows;/usr/lib/mxe/lib/libwx_baseu_net-3.1.a;/usr/lib/mxe/lib/libwx_mswu_adv-3.1.a;/usr/lib/mxe/lib/libwx_mswu_core-3.1.a;/usr/lib/mxe/lib/libwx_baseu-3.1.a;-lwxregexu-3.1-i686-w64-mingw32.static;-lwxexpat-3.1-i686-w64-mingw32.static;-lwxtiff-3.1-i686-w64-mingw32.static;-lwxjpeg-3.1-i686-w64-mingw32.static;-lwxpng-3.1-i686-w64-mingw32.static;-lz;-lrpcrt4;-loleaut32;-lole32;-luuid;-lwinspool;-lwinmm;-lshell32;-lshlwapi;-lcomctl32;-lcomdlg32;-ladvapi32;-lversion;-lwsock32;-lgdi32
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(170): wxWidgets_LIBRARY_DIRS=/usr/lib/mxe/lib
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(170): _cygpath_exe: _cygpath_exe-NOTFOUND
-- /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake(166): _filename: _filename-NOTFOUND
CMake Error at /net/deimos/usr/lib/mxe/usr/x86_64-unknown-linux-gnu/share/cmake-3.5/Modules/FindwxWidgets.cmake:900 (message):
wxWidgets wx/version.h file not found in
/usr/lib/mxe/lib/wx/include/i686-w64-mingw32.static-msw-unicode-static-3.1;/usr/lib/mxe/include/wx-3.1.
Call Stack (most recent call first):
CMakeLists.txt:55 (find_package)
-- Configuring incomplete, errors occurred!
See also "/net/deimos/home/user/acu/src/build-mxe/CMakeFiles/CMakeOutput.log".
```
However the file does exist:
```
[pts/18][user@phobos]:/net/deimos/home/user/acu/src/build-mxe$ ls -l /usr/lib/mxe/include/wx*/wx/version.h
-rw-r--r-- 1 user user 3694 Feb 21 01:11 /usr/lib/mxe/include/wx-3.1/wx/version.h
```
(my server's NFS share is mounted as /net/deimos, and on the desktop machine (phobos) /usr/lib/mxe is a symlink to /net/deimos/usr/lib/mxe)
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/16614CMakeCompilerId.cmake (share/cmake-3.7/Modules) Fails when run in Jenkins build2017-10-13T13:17:55-04:00patrickCMakeCompilerId.cmake (share/cmake-3.7/Modules) Fails when run in Jenkins buildI use git-bash bash shell when compiling cmake projects in windows. When I run cmake from bash shell it works fine, however when I run the same cmake with bash shell as jenkins job it fails. Log below.
I discovered that the length of...I use git-bash bash shell when compiling cmake projects in windows. When I run cmake from bash shell it works fine, however when I run the same cmake with bash shell as jenkins job it fails. Log below.
I discovered that the length of data returned in the line
file(READ ${file} peoffsethex LIMIT 1 OFFSET 60 HEX)
is shorted than expected, poffsethex from license file is empty.
When building regularly from shell, it appears that the license file is not even checked.
```
c:\jenkins_workspace\VT_R0>cd project_mw\verification_test
09:28:53
09:28:53 c:\jenkins_workspace\VT_R0\project_mw\verification_test>cmake . -G"Unix Makefiles" -DTARGET_CORE=0 -DTARGET_BUILD=ROM
09:28:53 -- Found metaware at C:/Users/Patrick.fitzpatrick/Metaware.2016.09/MetaWare/arc
09:28:54 READING OFFSET 60 from this FILE: C:/jenkins_workspace/VT_R0/project_mw/verification_test/CMakeFiles/3.7.2/CompilerIdC/.license_HCAC
09:28:54 CMake Error at C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeDetermineCompilerId.cmake:509 (string):
09:28:54 string begin index: 1 is out of range 0 - 0
09:28:54 Call Stack (most recent call first):
09:28:54 C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeDetermineCompilerId.cmake:36 (CMAKE_DETERMINE_COMPILER_ID_CHECK)
09:28:54 C:/Program Files/CMake/share/cmake-3.7/Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
09:28:54 CMakeLists.txt:17 (project)
[.license_HCAC](/uploads/e4cec30ec2eb2fcde418bb3cb8300129/.license_HCAC)
```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/16074Setting link_directories in toolchain file is only used for compiler tests, a...2017-10-13T13:17:56-04:00Kitware RobotSetting link_directories in toolchain file is only used for compiler tests, and inhibits effect of repeating the commandThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16074). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16074). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15269Toolchain file not loaded without C language enabled2018-04-28T09:16:21-04:00Kitware RobotToolchain file not loaded without C language enabledThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15269). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15269). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14367install(TARGETS) docs should note to use relative paths for xcompiles (Was: I...2017-10-13T13:18:30-04:00Kitware Robotinstall(TARGETS) docs should note to use relative paths for xcompiles (Was: IMPORTED_LOCATION does not work for cross-compiling)This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14367). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14367). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14300The _CMAKE_TOOLCHAIN_LOCATION variable doesn't work in combination with CMAKE...2018-04-28T09:16:22-04:00Kitware RobotThe _CMAKE_TOOLCHAIN_LOCATION variable doesn't work in combination with CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14300). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14300). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14096Ninja Generator Fails to Produce Valid File When Cross Compiling2017-10-13T13:18:30-04:00Kitware RobotNinja Generator Fails to Produce Valid File When Cross CompilingThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14096). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14096). Further discussion may take place here.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/13862Toolchain file changes do not get used on future configure runs2017-10-13T13:18:31-04:00Kitware RobotToolchain file changes do not get used on future configure runsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13862). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13862). Further discussion may take place here.