| Message ID | 20250730061807.1642753-1-raj.khem@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | libclc: Set LDFLAGS to BUILD_LDFLAGS in do_build_prepare_builtins | expand |
On 30 Jul 2025, at 07:18, Khem Raj <raj.khem@gmail.com> wrote: > > 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. Is the problem that the environment contains variables like LDFLAGS which are for the target, and cmake is respecting them when we’re doing a native build? Possibly, our toolchain files should be setting CMAKE_SHARED_LINKER_FLAGS_INIT to the variables don’t get used at all. But until we change the cmake class, I wonder if we should just nuke the environment when running CMake as there’s more variables than LDFLAGS to cause trouble? I can’t replicate your failure, but this seems to work in libclc: do_build_prepare_builtins() { env -i PATH=$PATH cmake … I’ve just sent a patch, can you test it? Ross
On Fri, Aug 1, 2025 at 5:59 AM Ross Burton <Ross.Burton@arm.com> wrote: > > On 30 Jul 2025, at 07:18, Khem Raj <raj.khem@gmail.com> wrote: > > > > 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. > > Is the problem that the environment contains variables like LDFLAGS which are for the target, and cmake is respecting them when we’re doing a native build? > right. toolchain-native.cmake overrides some and appends to some variables and LDFLAGS is not overridden but appended to. > Possibly, our toolchain files should be setting CMAKE_SHARED_LINKER_FLAGS_INIT to the variables don’t get used at all. But until we change the cmake class, I wonder if we should just nuke the environment when running CMake as there’s more variables than LDFLAGS to cause trouble? I can’t replicate your failure, but this seems to work in libclc: You need to build libclc from clang-21 for this to show up. If you are interested use kraj/clang-21 branch > > do_build_prepare_builtins() { > env -i PATH=$PATH cmake … > > I’ve just sent a patch, can you test it? Yes, this works too. > > Ross
diff --git a/meta/recipes-devtools/clang/libclc_git.bb b/meta/recipes-devtools/clang/libclc_git.bb index 7e63ce9c759..d09ea8cdb38 100644 --- a/meta/recipes-devtools/clang/libclc_git.bb +++ b/meta/recipes-devtools/clang/libclc_git.bb @@ -43,6 +43,7 @@ do_install:append() { # 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 \
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> --- meta/recipes-devtools/clang/libclc_git.bb | 1 + 1 file changed, 1 insertion(+)