6fc05011a1
Updated the Rust build to depend on llvm instead. *Summary of discussion with the rust upstream about using latest LLVM instead of Rust maintained LLVM fork. https://internals.rust-lang.org/t/can-we-use-proper-clang-instead-of-llvm-fork-what-rust-uses/23489 *Upstream LLVM is generally compatible: - Rust does support building with upstream (vanilla) LLVM, especially the latest major release and the one or two preceding ones. https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#updating-llvm *Impact on Yocto Rust upgrades: - Rust upgrades shall always check for updates on rust forked llvm and backport the relevant patches to llvm. *Regarding the rust forked llvm local patches: - There are no local patches on rust forked llvm other than the backported fixes from llvm master. *We are copying the natively built `llvm-config` binary into the target sysroot and running it. However, this `llvm-config` has compile time dependencies on various other arch's LLVM libraries because native-llvm is built for all oe-core supported targets. Attempting to work around this by symlinking the missing libraries from the native sysroot into the target sysroot leads to mixed architectures in the final `.rlib`. Specifically, the object files extracted from those symlinked libraries within `librustc_llvm-<hash>.rlib` are built for the host, while others are correctly built for the target This results in linker failures due to file format not recognized. To resolve this, we now build llvm-target also for all oe-core supported architectures in addition to the native-llvm build. This ensures that `llvm-config` and all associated libraries are built for the correct target, eliminating cross-architecture contamination and linker issues. *We are enabling -DLLVM_INSTALL_UTILS=ON to ensure essential LLVM utilities like FileCheck are available, as they are required by the Rust build. Without this, the build fails with an error as below: | thread 'main' panicked at src/bootstrap/src/core/sanity.rs:315:21: | FileCheck executable "poky/build/tmp/work/x86_64-linux/rust-native/1.90.0/recipe-sysroot -native/usr/bin/FileCheck" does not exist *We now add these flags "-Clink-arg=-lz -Clink-arg=-lzstd" because of this following diff otherwise we will get errors during link time. Setup in rust-llvm -DLLVM_ENABLE_ZLIB=OFF \ -DLLVM_ENABLE_ZSTD=OFF \ -DLLVM_ENABLE_FFI=OFF \ Setup in llvm -DLLVM_ENABLE_FFI=ON \ *When multilibs enabled: llvm-config expects static libraries to be located in the lib directory rather than lib64. However, since we are copying the natively built llvm-config to target sysroot and running it and llvm-config doesn't know anything about lib64 existence. To accommodate this without breaking multilib behavior, we are creating a symlink from 'lib' to 'lib64' directory. Previously, when we depended on rust-llvm, this worked because we specified: -DCMAKE_INSTALL_PREFIX:PATH=${libdir}/llvm-rust With this setup, llvm-config was installed inside ${libdir}/llvm-rust, which included its own bin and lib directories. Thus, llvm-config located in bin would correctly find the libraries in the adjacent lib directory. Even when multilib was enabled or not, llvm-config would still look for libraries under lib in this structure, so everything functioned as expected. (From OE-Core rev: 9b0a3484626ecb5e58004572caac7a8e8f86980c) Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.