| Message ID | 20221027185937.2023904-1-bero@baylibre.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/1] cmake-native: Fix host tool contamination (Bug: 14951) | expand |
diff --git a/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb b/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb index 722a486f20..bcc87eb8f2 100644 --- a/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb +++ b/meta/recipes-devtools/cmake/cmake-native_3.24.0.bb @@ -32,6 +32,7 @@ CMAKE_EXTRACONF = "\ -DCMAKE_USE_SYSTEM_LIBRARY_EXPAT=0 \ -DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \ -DHAVE_SYS_ACL_H=0 \ + -DCURL_LIBRARIES=-lcurl \ " do_configure () {
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. Signed-off-by: Bernhard Rosenkränzer <bero@baylibre.com> --- meta/recipes-devtools/cmake/cmake-native_3.24.0.bb | 1 + 1 file changed, 1 insertion(+)