Re: [CMake] cmake server-mode project order
Tobias Hunger wrote: On Feb 7, 2017 20:43, "Brad King" mailto:brad.k...@kitware.com>> wrote: On 02/07/2017 02:23 PM, Michael Jackson wrote: > Are there any improvements to the cmake -server mode? I am testing the > combination of QtCreator and CMake and there seemed to be an issue where > the list of projects are in Alphabetical order and not in a "top down" > order. Tobias? I admit that I did not yet notice that yet:-) I turn the whole thing into a tree anyway and do not care about the order of the elements. Server-mode is not doing anything special, it just grabs the project list from cmGlobalGenerator::GetProjectMap() and dumps it. That is a map, so now that I think about it, it is sorted by name:-) Yes, I could re-sort that to be in another order. Best Regards, Tobisa This comes off mainly as a visual issue but also a but of a usability issue. Our project is called "DREAM3D" but has a subproject called "AMProcessMonitoring". After loading the project in QtCreator 4.3 beta using CMake 3.7.1 (on OS X if that matters at all), the top level is listed as "AMProcessMonitoring". Everything generally compiles fine from there. If I close the project and go to QtCreators Welcome page I don't see "DREAM3D" anymore but I see "AMProcessMonitoring" instead. Clicking on the "AMProcessingMonitoring" link correctly opens the project. It is just odd to see it that way. So if you could somehow mark the top level project when you get the list from CMake and percolate that to the QtCreator UI it would be really great. So far the combination of QtCreator 4.3 and CMake 3.7.1 has really great potential. There are still some rough spots but I generally am really happy with this combination now. -- Michael A. Jackson 400 S. Pioneer Blvd Owner, President Springboro, Ohio 45066 BlueQuartz Software, LLC EMail: mike.jack...@bluequartz.net Voice: 937-790-1601Web: http://www.bluequartz.net Fax: 937-746-0783 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake server-mode project order (was: CMake 3.8.0-rc1 now ready for testing!)
On 02/07/2017 02:23 PM, Michael Jackson wrote: > Are there any improvements to the cmake -server mode? I am testing the > combination of QtCreator and CMake and there seemed to be an issue where > the list of projects are in Alphabetical order and not in a "top down" > order. Tobias? -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!
Are there any improvements to the cmake -server mode? I am testing the
combination of QtCreator and CMake and there seemed to be an issue where
the list of projects are in Alphabetical order and not in a "top down"
order.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net
Robert Maynard wrote:
I am proud to announce the first CMake 3.8 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.8
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.8/release/3.8.html
Some of the more significant changes in CMake 3.8 are:
* CMake now supports "CSharp" (C#) as a first-class language. It is
currently supported by the Visual Studio Generators for VS 2010
and above.
* CMake now supports "CUDA" as a first-class language. It is
currently supported by the Makefile Generators and the
"Ninja" generator on Linux, macOS, and Windows. Support for the
Visual Studio IDE is under development but not included in this
release.
* The "Compile Features" functionality now offers meta-features that
request compiler modes for specific language standard levels (e.g.
"cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and
"CMAKE_CXX_KNOWN_FEATURES".
* The "Compile Features" functionality is now aware of C++ 17. No
specific features are yet enumerated besides the "cxx_std_17" meta-
feature.
* The Visual Studio Generators for VS 2013 and above learned to
support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
(e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit
toolchain on 64-bit hosts.
* The Visual Studio Generators learned to treat files passed to
"target_link_libraries()" whose names end in ".targets" as MSBuild
"targets" files to be imported into generated project files.
* The "try_compile()" command source file signature gained new
options to specify the language standard to use in the generated
test project.
* The "try_compile()" command source file signature now honors
language standard variables like "CMAKE_CXX_STANDARD". See policy
"CMP0067".
* A "BUILD_RPATH" target property and corresponding
"CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
locations to be added to binaries in the build tree.
* The "COMPILE_FLAGS" source file property learned to support
"generator expressions".
* A new generator expression "$" was
added. It resolves to the true-value if the condition is "1" and
resolves to the false-value if the condition is "0".
* The "Compile Features" functionality is now aware of features
supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
and Windows platforms.
* The Visual Studio Generators for VS 2010 and above now place per-
source file flags after target-wide flags when they are classified
as raw flags with no project file setting ("AdditionalOptions").
This behavior is more consistent with the ordering of flags produced
by other generators, and allows flags on more-specific properties
(per-source) to override those on more general ones (per-target).
* The precompiled Windows binary MSI package provided on "cmake.org"
now records the installation directory in the Windows Registry under
the key "HKLM\Software\Kitware\CMake" with a value named
"InstallDir".
CMake 3.8 Release Notes
***
Changes made since CMake 3.7 include the following.
New Features
Languages
-
C#
~~
* CMake learned to support "CSharp" (C#) as a first-class language
that can be enabled via the "project()" and "enable_language()"
commands. It is currently supported by the Visual Studio Generators
for VS 2010 and above.
C# assemblies and programs can be added just like common C++ targets
using the "add_library()" and "add_executable()" commands.
References between C# targets in the same source tree may be
specified by "target_link_libraries()" like for C++. References to
system or 3rd-party assemblies may be specified by the target
properties "VS_DOTNET_REFERENCE_" and
"VS_DOTNET_REFERENCES".
* More fine tuning of C# targets may be done using target and source
file properties. Specifically the target properties related to
Visual Studio ("VS_*") are worth a look (for setting toolset
versions, root namespaces, assembly icons, ...).
* Auto-linking in ".csproj" files: In C#/.NET development with
Visual Studio there are a number of visual editors used which
generate code. Both the generated files and the ones edited with
the UI are connected in the ".csproj" file using ""
tags. If CMake finds within a C# project any source file with
extension ".Designer.cs" or ".xaml.cs", it checks sibling files with
extension ".xaml", ".settings", ".resx" or ".cs" and establishes the
dependency connection.
CUDA
* CMake learned to support "CUDA" as a f
[CMake] [ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!
I am proud to announce the first CMake 3.8 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.8
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.8/release/3.8.html
Some of the more significant changes in CMake 3.8 are:
* CMake now supports "CSharp" (C#) as a first-class language. It is
currently supported by the Visual Studio Generators for VS 2010
and above.
* CMake now supports "CUDA" as a first-class language. It is
currently supported by the Makefile Generators and the
"Ninja" generator on Linux, macOS, and Windows. Support for the
Visual Studio IDE is under development but not included in this
release.
* The "Compile Features" functionality now offers meta-features that
request compiler modes for specific language standard levels (e.g.
"cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and
"CMAKE_CXX_KNOWN_FEATURES".
* The "Compile Features" functionality is now aware of C++ 17. No
specific features are yet enumerated besides the "cxx_std_17" meta-
feature.
* The Visual Studio Generators for VS 2013 and above learned to
support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
(e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit
toolchain on 64-bit hosts.
* The Visual Studio Generators learned to treat files passed to
"target_link_libraries()" whose names end in ".targets" as MSBuild
"targets" files to be imported into generated project files.
* The "try_compile()" command source file signature gained new
options to specify the language standard to use in the generated
test project.
* The "try_compile()" command source file signature now honors
language standard variables like "CMAKE_CXX_STANDARD". See policy
"CMP0067".
* A "BUILD_RPATH" target property and corresponding
"CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
locations to be added to binaries in the build tree.
* The "COMPILE_FLAGS" source file property learned to support
"generator expressions".
* A new generator expression "$" was
added. It resolves to the true-value if the condition is "1" and
resolves to the false-value if the condition is "0".
* The "Compile Features" functionality is now aware of features
supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
and Windows platforms.
* The Visual Studio Generators for VS 2010 and above now place per-
source file flags after target-wide flags when they are classified
as raw flags with no project file setting ("AdditionalOptions").
This behavior is more consistent with the ordering of flags produced
by other generators, and allows flags on more-specific properties
(per-source) to override those on more general ones (per-target).
* The precompiled Windows binary MSI package provided on "cmake.org"
now records the installation directory in the Windows Registry under
the key "HKLM\Software\Kitware\CMake" with a value named
"InstallDir".
CMake 3.8 Release Notes
***
Changes made since CMake 3.7 include the following.
New Features
Languages
-
C#
~~
* CMake learned to support "CSharp" (C#) as a first-class language
that can be enabled via the "project()" and "enable_language()"
commands. It is currently supported by the Visual Studio Generators
for VS 2010 and above.
C# assemblies and programs can be added just like common C++ targets
using the "add_library()" and "add_executable()" commands.
References between C# targets in the same source tree may be
specified by "target_link_libraries()" like for C++. References to
system or 3rd-party assemblies may be specified by the target
properties "VS_DOTNET_REFERENCE_" and
"VS_DOTNET_REFERENCES".
* More fine tuning of C# targets may be done using target and source
file properties. Specifically the target properties related to
Visual Studio ("VS_*") are worth a look (for setting toolset
versions, root namespaces, assembly icons, ...).
* Auto-linking in ".csproj" files: In C#/.NET development with
Visual Studio there are a number of visual editors used which
generate code. Both the generated files and the ones edited with
the UI are connected in the ".csproj" file using ""
tags. If CMake finds within a C# project any source file with
extension ".Designer.cs" or ".xaml.cs", it checks sibling files with
extension ".xaml", ".settings", ".resx" or ".cs" and establishes the
dependency connection.
CUDA
* CMake learned to support "CUDA" as a first-class language that can
be enabled via the "project()" and "enable_language()" commands.
* "CUDA" is currently supported by the Makefile Generators and the
"Ninja" generator on Linux, macOS, and Windows. Support for the
Visual Studio IDE is under development but not included in this
release.
* The NVIDIA CUDA Toolkit compiler ("nvcc") is supported.
C & C++
~~~
* Th
[CMake] Why can't I build CMake on Centos6 32-bit?
This used to work. Linux build6.leepfrog.com 2.6.32-642.6.2.el6.i686 #1 SMP Wed Oct 26 06:14:53 UTC 2016 i686 i686 i386 GNU/Linux gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17) The first part of the bootstrap succeeds, and then running the second stage yields this: loading initial cache file /home/kwilliams/develop/cmake/build6/Bootstrap.cmk/InitialCacheFlags.cmake CMake Error at Modules/CMakeCompilerIdDetection.cmake:28 (list): list sub-command REMOVE_ITEM requires two or more arguments. Call Stack (most recent call first): Modules/CMakeDetermineCompilerId.cmake:114 (compiler_id_detection) Modules/CMakeDetermineCompilerId.cmake:132 (CMAKE_DETERMINE_COMPILER_ID_WRITE) Modules/CMakeDetermineCompilerId.cmake:30 (CMAKE_DETERMINE_COMPILER_ID_BUILD) Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:11 (project) CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file): file problem creating directory: /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC Call Stack (most recent call first): Modules/CMakeDetermineCompilerId.cmake:30 (CMAKE_DETERMINE_COMPILER_ID_BUILD) Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:11 (project) CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file): file problem creating directory: /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC Call Stack (most recent call first): Modules/CMakeDetermineCompilerId.cmake:30 (CMAKE_DETERMINE_COMPILER_ID_BUILD) Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:11 (project) CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file): file problem creating directory: /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdC Call Stack (most recent call first): Modules/CMakeDetermineCompilerId.cmake:30 (CMAKE_DETERMINE_COMPILER_ID_BUILD) Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:11 (project) -- The C compiler identification is unknown CMake Error: Could not find cmake module file: /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CMakeCCompiler.cmake CMake Error at Modules/CMakeCompilerIdDetection.cmake:28 (list): list sub-command REMOVE_ITEM requires two or more arguments. Call Stack (most recent call first): Modules/CMakeDetermineCompilerId.cmake:114 (compiler_id_detection) Modules/CMakeDetermineCompilerId.cmake:132 (CMAKE_DETERMINE_COMPILER_ID_WRITE) Modules/CMakeDetermineCompilerId.cmake:30 (CMAKE_DETERMINE_COMPILER_ID_BUILD) Modules/CMakeDetermineCXXCompiler.cmake:104 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:11 (project) CMake Error at Modules/CMakeDetermineCompilerId.cmake:131 (file): file problem creating directory: /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CompilerIdCXX Call Stack (most recent call first): Modules/CMakeDetermineCompilerId.cmake:30 (CMAKE_DETERMINE_COMPILER_ID_BUILD) Modules/CMakeDetermineCXXCompiler.cmake:104 (CMAKE_DETERMINE_COMPILER_ID) CMakeLists.txt:11 (project) -- The CXX compiler identification is unknown CMake Error: Could not find cmake module file: /home/kwilliams/develop/cmake/build6/CMakeFiles/3.7.2/CMakeCXXCompiler.cmake -- Check for working C compiler: /usr/bin/gcc CMake Error at Modules/CMakeTestCCompiler.cmake:37 (try_compile): Unknown extension ".c" for file /home/kwilliams/develop/cmake/build6/CMakeFiles/CMakeTmp/testCCompiler.c try_compile() works only for enabled languages. Currently these are: C CXX See project() command to enable other languages. Call Stack (most recent call first): CMakeLists.txt:11 (project) -- Check for working C compiler: /usr/bin/gcc -- broken CMake Error at Modules/CMakeTestCCompiler.cmake:51 (message): The C compiler "/usr/bin/gcc" is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:11 (project) -- Configuring incomplete, errors occurred! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
The PR Is closed pending me writing a test-case, but I just now
updated to the my latest version and rebased on top of master:
https://gitlab.kitware.com/mingwandroid/cmake/commit/b937ff949d8fdaab7d8b812d503f67f8cef69532
Cheers.
On Tue, Feb 7, 2017 at 8:37 AM, wrote:
> Hi Ray,
>
> Am 2017-02-07 02:46, schrieb Ray Donnelly:
>>
>> I have a PR that asks the linker (via the compiler) what its implicit
>> search directories are instead.
>>
>> It is the right way to do it IMHO, but I need to find time to finish
>> it unfortunately.
>
>
> Do you have a link to the PR?
>
>> On Feb 6, 2017 11:16 PM, "Jörg Krause"
>> wrote:
>>
>>> On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
Hi,
On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
>
> Hi,
>
> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> environment, CMake passes the host rpath to the linker:
>
> """ CMakeOutput.log
>
> /home/joerg/host/usr/bin/i586-linux-gcc
> --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -Os -
> DNDEBUG CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o -o
> cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
> /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> /home/joerg/host/usr/i586-buildroot-linux-
> musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
>
> """
>
> This leads to a linker error if mbedtls is linked with zlib, as
>>>
>>> the
>
> linker tries to link with the host zlib and does not find the
>>>
>>> host
>
> libc:
>
> """ CMakeError.txt
>
> /home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
> libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
> -rpath
> or -rpath-link)
> /usr/lib32/libz.so.1: undefined reference to `strcpy@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> [..]
>
> """
>
> I did not find any solution which allows me to remove the rpath
> from
> the check. Setting CMAKE_SKIP_RPATH does not change the build
> behaviour of the check_symbol_exists macro.
>
> From my understanding, the rpath flag should not be used when
>>>
>>> the
>
> sysroot flag is passed to the linker, right?
>
> For reference, I added a minimal example which uses Buildroot
>>>
>>> for
>
> cross-compilation.
>
> """ CMakeLists.txt
>
> cmake_minimum_required(VERSION 2.8.12)
>
> project(test)
>
> list(APPEND CMAKE_MODULE_PATH
>>>
>>> "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
>
>
> find_package(MbedTLS)
> if(MBEDTLS_FOUND)
> message(STATUS "Using mbedTLS")
> endif()
>
> """
>
> """ FindMbedTLS.cmake
>
> include(CheckSymbolExists)
>
> find_path(MBEDTLS_INCLUDE_DIRS
> NAMES mbedtls/ssl.h
> PATH_SUFFIXES include
> )
>
> find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> find_library(MBEDX509_LIBRARY NAMES mbedx509)
> find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
>
> if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> MBEDTLS_V2)
> endif()
>
> """
>
> """ toolchainfile.cmake
>
> string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> ${CMAKE_CURRENT_LIST_DIR})
>
> set(CMAKE_SYSTEM_NAME Linux)
> set(CMAKE_SYSTEM_PROCESSOR i586)
>
> set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> CFLAGS")
> set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> CXXFLAGS")
>
> # Build type from the Buildroot configuration
> set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> configuration")
>
> # Buildroot defaults flags.
> set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS
>>>
>>> for
>
> executables")
>
> set(CMAKE_INSTALL_SO_NO_EXE 0)
>
> set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> set(CMAKE_SYSROOT
>>>
>>> "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
>
> musl/sysroot")
> set(
Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
Hi Ray,
Am 2017-02-07 02:46, schrieb Ray Donnelly:
I have a PR that asks the linker (via the compiler) what its implicit
search directories are instead.
It is the right way to do it IMHO, but I need to find time to finish
it unfortunately.
Do you have a link to the PR?
On Feb 6, 2017 11:16 PM, "Jörg Krause"
wrote:
On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
Hi,
On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
Hi,
when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
environment, CMake passes the host rpath to the linker:
""" CMakeOutput.log
/home/joerg/host/usr/bin/i586-linux-gcc
--sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-Os -
DNDEBUG CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o -o
cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
/home/joerg/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
/home/joerg/host/usr/i586-buildroot-linux-
musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
"""
This leads to a linker error if mbedtls is linked with zlib, as
the
linker tries to link with the host zlib and does not find the
host
libc:
""" CMakeError.txt
/home/joerg/host/usr/i586-buildroot-linux-musl/bin/ld: warning:
libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using
-rpath
or -rpath-link)
/usr/lib32/libz.so.1: undefined reference to `strcpy@GLIBC_2.0'
/usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
/usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
[..]
"""
I did not find any solution which allows me to remove the rpath
from
the check. Setting CMAKE_SKIP_RPATH does not change the build
behaviour of the check_symbol_exists macro.
From my understanding, the rpath flag should not be used when
the
sysroot flag is passed to the linker, right?
For reference, I added a minimal example which uses Buildroot
for
cross-compilation.
""" CMakeLists.txt
cmake_minimum_required(VERSION 2.8.12)
project(test)
list(APPEND CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake")
find_package(MbedTLS)
if(MBEDTLS_FOUND)
message(STATUS "Using mbedTLS")
endif()
"""
""" FindMbedTLS.cmake
include(CheckSymbolExists)
find_path(MBEDTLS_INCLUDE_DIRS
NAMES mbedtls/ssl.h
PATH_SUFFIXES include
)
find_library(MBEDTLS_LIBRARY NAMES mbedtls)
find_library(MBEDX509_LIBRARY NAMES mbedx509)
find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
MBEDTLS_V2)
endif()
"""
""" toolchainfile.cmake
string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
${CMAKE_CURRENT_LIST_DIR})
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR i586)
set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
CFLAGS")
set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
CXXFLAGS")
# Build type from the Buildroot configuration
set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
configuration")
# Buildroot defaults flags.
set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS
for
executables")
set(CMAKE_INSTALL_SO_NO_EXE 0)
set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
set(CMAKE_SYSROOT
"${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
musl/sysroot")
set(CMAKE_FIND_ROOT_PATH
"${RELOCATED_HOST_DIR}/usr/i586-buildroot-
linux-musl/sysroot")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
buildroot-linux-musl/sysroot")
# This toolchain file can be used both inside and outside
Buildroot.
set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
gcc")
set(CMAKE_CXX_COMPILER
"${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
g++")
"""
What do I miss?
Note, that this project was build using CMake 3.7.2 on Debian.
When
using CMake 3.6.3, CMake does correctly not add rpath to the
cross-
linker and the check_symbol_exists() succeeds.
I did a git bisect. The behaviour was introduced in commit
896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.
[1]
https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3
cbbcf9a6cce85a
