meta-clang
meta-clang copied to clipboard
Question on bootstrapping nativesdk-clang
Hi Khem,
Currently, I am trying to enable a bootstrapped clang for RISC-V target in my Yocto SDK (-c populate_sdk) using the meta-clang and meta-riscv honister branches. I want to ask if is there a need for bootstrapping the nativesdk-clang variant, when the clang-native is already bootstrapped by enabling the 'bootstrap' in PACKAGECONFIG.
From what I had found out, since clang only build once for one host (clang-native), does it means that we dont actually need to bootstrap nativesdk-clang again? Or are there any LLVM build options that we need to include for the nativesdk variant?
This is because during stage2-configure for nativesdk-clang, the nativesdk-clang built in stage 1 appears to be not found:
Error faced during stage-2 configure on nativesdk-clang:
| /bin/sh: 1: /home/alleria/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/./bin/clang: not found | ninja: build stopped: subcommand failed. | | | | | | CMake will not be able to correctly generate this project. | Call Stack (most recent call first): | CMakeLists.txt:44 (project) | | | -- Configuring incomplete, errors occurred! | See also "/home/alleria/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/tools/clang/stage2-bins/CMakeFiles/CMakeOutput.log". | See also "/home/alleria/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/tools/clang/stage2-bins/CMakeFiles/CMakeError.log". | FAILED: tools/clang/stage2-stamps/stage2-configure /home/alleria/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/tools/clang/stage2-stamps/stage2-configure
However, apparently the clang file is there, so I suspect this may be due the nativesdk-clang build is built for the to-be-installed-SDK path, so there is some problem with the dynamic linker (or anything else)? Here's the file info (not sure if it helps):
$ file /home/alleria/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/./bin/clang
/home/alleria/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/./bin/clang: symbolic link to clang-13$ file /home/alleria/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/./bin/clang-13
/home/riscv-yocto/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-clang/13.0.0-r0/build/./bin/clang-13: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-oesdk-linux/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
My Build
I am building the SDK image with MACHINE=qemuriscv64 bitbake core-image-full-cmdline -c populate_sdk and the layers:
- meta-clang honister branch
- meta-riscv honister branch
- meta-openembedded honister branch
- openembedded-core honister branch
- bitbake 1.52
Is there anything that I may be missing out? Is it some kind of LLVM build option issue, or RISC-V issue, or nativesdk-clang is not meant to be bootstrapped? (kinda new to bootstrapping) Thanks!
nativesdk-clang is needed because we use uninative shim layer to redirect loading of SDK tools when installed on SDK machine, so the SDK can work on multiple distros. I am able to build SDKs on master branch for qemuriscv64