meta-clang icon indicating copy to clipboard operation
meta-clang copied to clipboard

Question on bootstrapping nativesdk-clang

Open alleriino opened this issue 3 years ago • 1 comments

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:

  1. meta-clang honister branch
  2. meta-riscv honister branch
  3. meta-openembedded honister branch
  4. openembedded-core honister branch
  5. 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!

alleriino avatar Feb 21 '22 16:02 alleriino

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

kraj avatar Feb 21 '22 16:02 kraj