Re: [OE-core] [PATCH v2 03/15] rust: install Rust library sources for 'make rustavailable' support

[Harish Sadineni <Harish.Sadineni@windriver.com>]

On 1/12/2026 6:12 AM, Alistair Francis wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Thu, Jan 8, 2026 at 4:22 AM Randy MacLeod via
> lists.openembedded.org
> <randy.macleod=windriver.com@lists.openembedded.org> wrote:
>> On 2026-01-07 11:34 a.m., Harish Sadineni wrote:
>>
>>
>> On 1/7/2026 12:29 AM, Randy MacLeod wrote:
>>
>> On 2026-01-05 11:24 a.m., Harish Sadineni wrote:
>>
>>
>> On 12/30/2025 9:28 PM, Richard Purdie wrote:
>>
>> CAUTION: This email comes from a non Wind River email account!
>> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>
>> On Tue, 2025-12-30 at 06:15 -0800, Sadineni, Harish via lists.openembedded.org wrote:
>>
>> From: Harish Sadineni <Harish.Sadineni@windriver.com>
>>
>> The `make rustavailable` process (1) expects the Rust standard library source files (e.g., `lib.rs`)
>> to be present in the `library/` directory under `rustlib/src/rust/`.
>>
>> This patch ensures the required sources are available by:
>> - Copying the `library/` directory from the Rust source tree into `${TMPDIR}/work-shared/rust`
>>     during the snapshot setup.
>> - Installing the `library/` directory into `${SDKPATHNATIVE}/usr/lib/rustlib/src/rust` for the
>>     `nativesdk` class, making them available in them available in sdk
>>
>> 1) See the kernel tree for Documentation/rust/quick-start.rst in the section: Requirements: Building
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rust/quick-start.rst#n145
>>
>> Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
>> ---
>>    meta/recipes-devtools/rust/rust_1.91.1.bb | 17 +++++++++++++++++
>>    1 file changed, 17 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/rust/rust_1.91.1.bb b/meta/recipes-devtools/rust/rust_1.91.1.bb
>> index a25f65f674..7644ecf2d2 100644
>> --- a/meta/recipes-devtools/rust/rust_1.91.1.bb
>> +++ b/meta/recipes-devtools/rust/rust_1.91.1.bb
>> @@ -63,6 +63,16 @@ do_rust_setup_snapshot () {
>>            done
>>        fi
>>    }
>> +
>> +do_rust_setup_snapshot:append:class-native () {
>> +   if ${@bb.utils.contains('DISTRO_FEATURES', 'rust-kernel', 'true', 'false', d)}; then
>> +         if [ ! -d "${TMPDIR}/work-shared/rust" ]; then
>> +                mkdir -p ${TMPDIR}/work-shared/rust
>> +                cp -r ${RUSTSRC}/library ${TMPDIR}/work-shared/rust/.
>> +         fi
>> +   fi
>> +}
> Note you can just use the Rust bootstrap tool to install the source,
> see my patch here:
> https://lists.openembedded.org/g/openembedded-core/topic/patch_1_2_rust_install_the/117170671
>
> That way you don't need to manually copy the files
Yes, that works. However, when using the above method to install the 
sources, 'bitbake make-mod-scripts' fails with the following error:

HOSTRUSTC scripts/generate_rust_target
error: Unrecognized option: 'i'

This issue occurs because CFLAGS are being passed to HOSTRUSTC. I have 
updated the flags in the make-mod-scripts recipe to align with the flags 
used by linux-yocto.
In addition, I fixed some build path issues and packaged the Rust 
library sources separately.

We are currently testing the changes and will send v3 within the next 
couple of days.

Thanks,
Harish
>
>> +
>>    addtask rust_setup_snapshot after do_unpack before do_configure
>>    addtask do_test_compile after do_configure do_rust_gen_targets
>>    do_rust_setup_snapshot[dirs] += "${WORKDIR}/rust-snapshot"
>> @@ -314,6 +324,13 @@ rust_do_install:class-nativesdk() {
>>         export CARGO_TARGET_${RUST_HOST_TRIPLE}_RUNNER="\$OECORE_NATIVE_SYSROOT/lib/${SDKLOADER}"
>>         export CC_$RUST_HOST_CC="${CCACHE}${HOST_PREFIX}gcc"
>>         EOF
>> +
>> +    if ${@bb.utils.contains('DISTRO_FEATURES', 'rust-kernel', 'true', 'false', d)}; then
>> +           if [ ! -d ${D}${SDKPATHNATIVE}/usr/lib/rustlib/src/rust ]; then
>> +                mkdir -p ${D}${SDKPATHNATIVE}/usr/lib/rustlib/src/rust
>> +                cp -r --no-preserve=ownership  ${S}/library ${D}${SDKPATHNATIVE}/usr/lib/rustlib/src/rust/
>> +           fi
>> +    fi
>>    }
>>
>>    FILES:${PN} += "${base_prefix}/environment-setup.d"
>>
>> The commit message should mention the size of these files.
>>
>> Ok sure, I will add file size in v3.
>>
>> Does this make sense as a distro feature or should we just do this all the time?
>>
>> This is suggestion from Bruce that we take it as distro feature.
>> https://lists.openembedded.org/g/openembedded-core/message/225256
>>
>>
>>
>> Richard mentioned this thread in today's tech call when I asked for commentson the rust-kernel PR.
>>
>> Yes, the high level requirement is to have a DISTRO_FEATURE but common, infrastructure parts
>> such as this code that just copies a hopefully small number of files around,
>> and is part of the rust recipe, could and likely be done regardless of the rust-kernel DISTRO_FEATURE.
>>
>>
>> Ok sure, We will remove the dependency on DISTRO_FEATURE  for copying the library directory from rust recipe.
>>
>>
>> Hold on, I said "small number of files...". See below.
>>
>>
>>
>> We don't want the rust recipe to change based on a kernel config unless we *really* have to
>> since that essentially doubles the testing that should be done or leaves a gap in testing of the
>> rust builds. If you do that for the kernel first, then another recipe later, soon you have a maintenance mess.
>>
>> Also if the kernel needs these files, then it's likely that other software will need it as well.
>> You should analyze why the kernel needs these files and why other recipes do not. Perhaps any
>> kernel-like image will have the same requirement. Is there a baremetal image  using rust anywhere
>> that you can use to check on that? I looked but all I found was:
>> https://github.com/ahcbb6/baremetal-helloqemu-rust
>> Anyway, let's focus on the linux kernel's requirements for now.
> The kernel needs the Rust core souce as the kernel is cross compiling
> the Rust source in it's build system.
>
> It seems unlikely that other software will do the same. It's a bit of
> a niche Linux kernel thing to want to do.
>
>>
>> So, how many files are needed and how much FS space do they use?
>>
>>
>> The file size of the library directory is around 50MB.
>>
>>
>> I've been around since the 1990s, 50 MB doesn't seem small to me but
>> let's see what other people think.
>>
>> Also, how may files is that?
>>
>> What's the content?  ls -lR if the list isn't too long.
>>
>> Does the kernel build need each and every file ? How did you check?
>> Can we automate the generation of the list of required files by scraping the data from the kernel perhaps?
> It's the core Rust library. Even if the kernel only uses a select
> number of files, those files will pull in other files and modules.
> Copying a subset of files would require editing the files to remove
> imports to the missing files and seems very prone to breakage.
>
> I agree 50MB isn't great, but it allows the rust-native package to
> build the kernel without rebuliding rust-native, which seems like a
> win.
>
>>
>>
>>
>> What are other build systems (gentoo for example) doing with their Rust builds to satisfy the kernel's rust requirements?
>>
>>
>> I will check and update on this.
>>
>>
>> Thanks.
>>
>>
>>
>>
>> In future when rust is default in kernel we can change this, But till then it is good to have it as a distro feature.
>>
>> Do the nativesdk components get packaged separately? If they were, we
>> could then make that an SDK feature instead.
>>
>> No, We are not packaging it separately.
>>
>>
>>
>> The questions seems to be whether we should create a separate packaging rule.
>>
>>
>> Now by default it is getting packaged with nativesdk-rust, Do we need a separate packaging for libraries/files that being installed for rust in kernel support?
> The Rust tooling actually does this (it's called rust-src) so maybe a
> rust-src-native package would be the way to go
>
> Alistair
>
>>
>>
>> What happens for on target kernel module development? Shouldn't there be a target package too?
>>
>> Yes, I have made the necessary changes to include Rust library for target as well and have tested Rust-based kernel module development on the target.
>> I will send updated patches with v3.
>>
>>
>>
>> Before you spend time on polishing v3 please explain what your workflow is, step by step,
>> so we can be sure that things makes sense from a high level.
>>
>> We will update the rust recipe to copy the required libs to target image and then the below steps to be followed :
>>
>>
>> This part we're still trying to work out...
>>
>> - Build the image by adding the required tools via IMAGE_INSTALL:append ( e.g kernel-devsrc, gcc, rust, cargo, bindgen-cli etc..).
>>
>> We could create / extend a packagegroup or use:
>>     meta/recipes-extended/images/core-image-kernel-dev.bb
>>
>> Bruce, what approach do you use / prefer ?
>>
>>
>> - In /usr/src/kernel, run "make rustavailable" to verify Rust support (This step will check all supporting tools are available for rust support in kernel).
>> - Run "make menuconfig" and enable "CONFIG_RUST".
>> - Run "make scripts" and "make prepare".
>> - Write a kernel module in Rust & build the module using "make", which generates the "module_name.ko" file.
>> - Load the module using "insmod module_name.ko".
>>
>>
>> The rest seems sensible to a non-kernel guy like me.
>>
>> Thanks,
>>
>> ../Randy
>>
>>
>> Thanks,
>> Harish
>>
>> ../Randy
>>
>>
>>
>> Thanks,
>> Harish
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> --
>> # Randy MacLeod
>> # Wind River Linux
>>
>>
>> --
>> # Randy MacLeod
>> # Wind River Linux
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#229026): https://lists.openembedded.org/g/openembedded-core/message/229026
>> Mute This Topic: https://lists.openembedded.org/mt/116997864/3619028
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alistair23@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>