Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
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 -DNDEBUGCMakeFiles/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 &qu
Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS
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 -
> > DNDEBUGCMakeFiles/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
[CMake] RPATH cross-compile issue with CHECK_*_EXISTS
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 -DNDEBUGCMakeFiles/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?
Best regards,
Jörg Krause
--
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
[CMake] Cross-compilation issue with CHECK_SYMBOL_EXISTS
Hi,
I have an issue using CMake for cross-compiling bctoolbox on a Debian
64-bit host system as a 32-bit target. The issue is in how the linker
works when using CHECK_SYMBOL_EXISTS.
bctoolbox uses its own module FindMbedTLS.cmake to check for the symbol
`mbedtls_ssl_init`:
"""
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)
cmake_push_check_state(RESET)
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)
cmake_pop_check_state()
endif()
"""
The check fails because the linker tries to link with the host zlib:
"""
/home/test/autobuild/run/instance-2/output/host/usr/bin/i586-linux-
gcc --sysroot=/home/test/autobuild/run/instance-
2/output/host/usr/i586-buildroot-linux-musl/sysroot -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -
DNDEBUGCMakeFiles/cmTC_4cdd8.dir/CheckSymbolExists.c.o -o
cmTC_4cdd8 -Wl,-rpath,/usr/lib32 -rdynamic
/home/test/autobuild/run/instance-2/output/host/usr/i586-buildroot-
linux-musl/sysroot/usr/lib32/libmbedtls.so
/home/test/autobuild/run/instance-2/output/host/usr/i586-buildroot-
linux-musl/sysroot/usr/lib32/libmbedx509.so
/home/test/autobuild/run/instance-2/output/host/usr/i586-buildroot-
linux-musl/sysroot/usr/lib32/libmbedcrypto.so
/home/test/autobuild/run/instance-2/output/host/opt/ext-
toolchain/bin/../lib/gcc/i586-buildroot-linux-
musl/5.4.0/../../../../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'
"""
As you can see, the linker uses `-Wl,-rpath,/usr/lib32` which should
not be used when cross-compiling. I had no success in using any CMAKE
symbol to get rid of this linker flag.
The toolchain file:
"""
#
# Automatically generated file; DO NOT EDIT.
# CMake toolchain file for Buildroot
#
# In order to allow the toolchain to be relocated, we calculate the
# HOST_DIR based on this file's location:
$(HOST_DIR)/usr/share/buildroot
# and store it in RELOCATED_HOST_DIR.
# All the other variables that need to refer to HOST_DIR will use the
# RELOCATED_HOST_DIR variable.
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++")
"""
Any idea how to fix the linking issue?
Best regards,
Jörg Krause
--
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
On Mon, 2017-02-27 at 16:33 -0500, Brad King wrote: > On 02/27/2017 03:50 PM, Jörg Krause wrote: > > The problem is... > > Thanks. I've opened an issue for this here: > > https://gitlab.kitware.com/cmake/cmake/issues/16682 Great! > > > These are set on by default in `Modules/Platform/UnixPaths.cmake` > > > but > > > disabled on Debian by `Modules/Platform/Linux.cmake` except when > > > cross compiling. If a toolchain file specifies CMAKE_SYSTEM_NAME > > > such that a custom `Platform/MySystem.cmake` file is loaded then > > > the latter can set them as needed for the target platform. > > > > Thanks for the hint. We are discussing this setting as a > > workaround. > > It sounds like this target platform does not want the lib32/lib64 > suffixes to be searched so this would be an appropriate setting > for the projects to use regardless of what is done about this in > upstream CMake. That will also fix it for using CMake 3.7. Buildroot does not have any problems with searching for libraries in lib32. It does have a problem with having a host rpath used for linking with libraries. So, turning of the search for lib32 is really just a workaround to get rid of the host rpath. From my understanding, there are some possibilities to fix this issue: 1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is enabled, and only search in lib32 in case the target is not found in lib. 2) Make sure, in case lib32 is a symlink, to follow the symlink. 3) Make sure, in case lib32 is a symlink to lib and is not included in the linker search paths, to add it to the implicit runtime search paths. Any thoughts? Jörg -- 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
Hi Brad, On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote: > On 02/07/2017 04:40 AM, Ray Donnelly wrote: > > > > 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? > > > > 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: > > The MR was: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/207 > > See discussion there for why it has not yet been accepted. Basically > I'd like to see a clear explanation of the use case. The case > described > in the MR looks to me like the custom compiler should be configured > to > always pass the needed rpath flags to the linker. > > On 02/06/2017 06:16 PM, Jörg Krause wrote: > > I did a git bisect. The behaviour was introduced in commit > > 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1]. > > Thanks for the bisect. I don't think there is anything wrong with > that > change on its own. It merely exposed some existing behavior in a new > case. The problem is, that we end up with a host rpath when cross-compiling which breaks compilations for a number of CMake packages we build on Buildroot. Buildroot uses /sysroot/usr/lib as target library path and /sysroot/usr/lib32 is a symlink to that path. Nothing wrong here. The addition of FIND_LIBRARY_USE_LIB32_PATHS changes the behavior of `find_library()`. Before the commit `/sysroot/usr/lib` was found as library path, but now it's `/sysroot/usr/lib32`. When determining the runtime search path, CMake compares the paths found by `find_library()` with a list of implicit runtime pathes. This list contains `/sysroot/usr/lib` but not `/sysroot/usr/lib32`. If the library path found by `find_library()` matches a search path from the list of implicit runtime pathes it is dropped, otherwise it is added to rpath after removing the `/sysroot` path. So, as the implicit runtime search paths does *not* contain `/sysroot/usr/lib32`, find_library() ends up with a rpath set to `/usr/lib32`. One example of how cross-compilation is broken is the example I already quoted: """ $SYSROOT/usr/bin/i586-linux-gcc --sysroot=$SYSROOT/usr/i586-buildroot- linux-musl/sysroot CheckSymbolExists.c.o -o cmTC_cb8f6 -Wl,- rpath,/usr/lib32 -rdynamic $SYSROOT/usr/i586-buildroot-linux- musl/sysroot/usr/lib32/libmbedtls.so """ If libmbedtls is linked with libz, the linker tries to link the target libmbedtls with host libz, which fails: """ $SYSROOT/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 """ Note, that Buildroot does not use a /sysroot/usr/lib64 symbolic link. Therefore, this behavior was not exposed before the commit. For me, it looks like there is a problem how the rpath is created when cross-compiling. Maybe the logic should check, if /sysroot/usr/lib32 is a symlink to an implicit runtime search path? However, I am not very familiar with CMake and the insights I described where gathered by some hours of debugging the CMake code. Maybe I missed something? > > My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and > > FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on > > Linux. > > These are set on by default in `Modules/Platform/UnixPaths.cmake` but > disabled on Debian by `Modules/Platform/Linux.cmake` except when > cross compiling. If a toolchain file specifies CMAKE_SYSTEM_NAME > such that a custom `Platform/MySystem.cmake` file is loaded then > the latter can set them as needed for the target platform. Thanks for the hint. We are discussing this setting as a workaround. Best regards, Jörg Krause -- 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
On Tue, 2017-02-28 at 08:22 -0500, Brad King wrote: > On 02/28/2017 05:25 AM, Jörg Krause wrote: > > Buildroot does not have any problems with searching for libraries > > in > > lib32. It does have a problem with having a host rpath used for > > linking > > with libraries. > > From your description we are not adding a host rpath. It's coming > from > /sysroot/usr/lib32 which is converted to /usr/lib32 by stripping the > sysroot. If you were to run the binary purely in the target > environment > then it would find the library in the target's /usr/lib32. It is not > clear to my how the binary is being run on the host, but doing so > uses > the host's /usr/lib32 because the binary was built for the target. > > > From my understanding, there are some possibilities to fix this > > issue: > > 1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is > > enabled, > > and only search in lib32 in case the target is not found in lib. > > The purpose of that features is so on a 64-bit system with 64-bit > libs > in `lib` and 32-bit libs in `lib32` that we find the latter when the > target architecture is 32 bit. > > > 2) Make sure, in case lib32 is a symlink, to follow the symlink. > > I was thinking the same thing. The lib => lib32 search path > conversion > should just be skipped if lib32 is a symlink back to lib. > > > 3) Make sure, in case lib32 is a symlink to lib and is not included > > in > > the linker search paths, to add it to the implicit runtime search > > paths. > > Yes, the issue I filed is about handling symlinks when comparing > rpath > entries to the list of implicit directories. > > I encourage you to sign up on gitlab.kitware.com to join discussion > in > that issue. I move the discussion to the gitlab issue: https://gitlab.kitware.com/c make/cmake/issues/16682 Jörg -- 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
