@@ -212,11 +212,14 @@ set( CMAKE_LIBRARY_PATH ${STAGING_BASE_LIBDIR_NATIVE} ${STAGING_LIBDIR_NATIVE})
list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${STAGING_INCDIR_NATIVE})
list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES ${STAGING_INCDIR_NATIVE})
-# We need to be sure that the environment variables exported by bitbake.conf
-# which are for the _target_ build are not respected, as otherwise you can
-# end up mixing native and target flags.
+# The assignmens above override CFLAGS and CXXFLAGS from the environment but
+# not LDFLAGS, which ends up in CMAKE_EXE_LINKER_FLAGS. This then means our
+# native builds use target flags, and can fail.
#
-# https://cmake.org/cmake/help/latest/manual/cmake-env-variables.7.html#environment-variables-for-languages
+# As there are a number of variables that are set from LDFLAGS,
+# clear it at source.
+#
+# https://cmake.org/cmake/help/latest/envvar/LDFLAGS.html
unset(ENV{LDFLAGS})
EOF
}
If a recipe is using toolchain-native.cmake to build native portion in a non-native build, the target LDFLAGS from the environment will leak into the native build. This was noticed as building a SDK with clang means that LDFLAGS contains a --dynamic-loader argument, so native binaries were trying to use the target loader. There are several variables that are set from LDFLAGS[1] so instead of setting them all, we can simply unset the environment variable in the toolchain. [1] https://cmake.org/cmake/help/latest/envvar/LDFLAGS.html Signed-off-by: Ross Burton <ross.burton@arm.com> --- meta/classes-recipe/cmake.bbclass | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)