This function is compiling a native binary, however its operating
largely inside a target or nativesdk shell environment. It does
tricks by passing toolchain-native.cmake to provide native
overrides for cmake, which works for most of variables of interest
besides LDFLAGS. In the toolchain.cmake files on OE we do not
override LDFLAGS but append to it via CMAKE_CXX_LINK_FLAGS or
CMAKE_C_LINK_FLAGS, which causes problems because LDFLAGS for
nativesdk will contain --dynamic-linker option pointing into
nativesdk string and when doing target build it will use the
LDFLAGS from target environment which might work if it does
not contain conflicting flags.
Currently prepare_builtins binary durin nativesdk build ends up with
[Requesting program interpreter: /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-yoesdk-linux/lib/ld-linux-x86-64.so.2]
This is because LDFLAGS for nativesdk contain the --dynamic-linker
flags pointing into this path.
Target builds for musl targets also end up with similar problems
So lets pass LDFLAGS=BUILD_LDFLAGS to fix this problem
Should toolchain.cmake class define CMAKE_EXE_LINKER_FLAGS,
CMAKE_SHARED_LINKER_FLAGS, CMAKE_MODULE_LINKER_FLAGS etc. as well
is a question that deserve a separate discussion
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
# Need to build a native prepare_builtins binary in target builds. The easiest
# way to do this is with a second native cmake build tree.
do_build_prepare_builtins() {
+ export LDFLAGS="${BUILD_LDFLAGS}"
cmake --fresh -G Ninja \
-S ${OECMAKE_SOURCEPATH} -B ${B_NATIVE} \
-DCMAKE_TOOLCHAIN_FILE:FILEPATH=${WORKDIR}/toolchain-native.cmake \