diff options
author | Bernhard Rosenkränzer <bero@baylibre.com> | 2022-10-27 21:47:49 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2022-10-29 16:28:35 +0100 |
commit | bd156c4618aed51d2b0a3c3bc4f6d619c51d3989 (patch) | |
tree | 11a6bdd496e750ad80d20112324c929938691b1b /scripts/lib/scriptpath.py | |
parent | d1cd7dc31c954af6bb925cda60b915397ab2944c (diff) | |
download | poky-bd156c4618aed51d2b0a3c3bc4f6d619c51d3989.tar.gz |
cmake-native: Fix host tool contamination
[v2 hopefully fixes the From: mangling by the ML, no functional changes]
Trying to build cmake-native on a host system where curl was built with cmake
(resulting in CURLConfig.cmake and friends, which do not use the same naming
schemes expected by cmake-native's build process, being installed to a system
wide cmake directory like /usr/lib64/cmake/CURL) results in undefined
references to all libcurl symbols.
The problem is that cmake-native sees and uses the system wide
/usr/lib64/cmake/CURL/CURLConfig.cmake, which defines CURL::libcurl and
CURL::curl as opposed to setting ${CURL_LIBRARIES} as expected by
cmake-native.
find_package(CURL) (cmake-native's CMakeLists.txt, line 478) succeeds, but
incorrectly uses the system wide CURLConfig.cmake, resulting
CMAKE_CURL_LIBRARIES to be set to an empty string (cmake-native's
CMakeLists.txt, line 484), causing the cmake-native build to miss -lcurl.
The simplest fix is to let cmake know the right value for
CURL_LIBRARIES. Making it -lcurl should always work with libcurl-native
in recipe-sysroot-native.
[YOCTO #14951]
(From OE-Core rev: 2659c735a464c956b4fca0894a5aed27a0fe7e37)
Signed-off-by: Bernhard Rosenkränzer <bero@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'scripts/lib/scriptpath.py')
0 files changed, 0 insertions, 0 deletions