Rust stable version updated to 1.84.1.
https://blog.rust-lang.org/2025/01/30/Rust-1.84.1.html
Renamed and modified the below patch to adapt the new version.
rv32-cargo-rustix-0.38.37-fix.patch->rv32-cargo-rustix-0.38.38-fix.patch
Modified the below patches to adapt the new version.
repro-issue-fix-with-cc-crate-hashmap.patch
revert-link-std-statically-in-rustc_driver-feature.patch
Dropped the below patches :
0001-NFC-fix-build-failure-100993.patch
6ee49080e4
revert-Zdual-proc-macros-additional-check.patch
Issue is fixed in rust-master and the fix is backported in the
subsequent patch of the series.
(From OE-Core rev: 4265f668de8c6708cb3a003ad655559031724149)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rust stable version updated to 1.83.0.
https://blog.rust-lang.org/2024/11/28/Rust-1.83.0.html
Renamed and modified the below patch to adapt the new version.
rv32-cargo-rustix-0.38.34-fix.patch->rv32-cargo-rustix-0.38.37-fix.patch
Modified the below patches to adapt the new version.
repro-issue-fix-with-cc-crate-hashmap.patch
revert-link-std-statically-in-rustc_driver-feature.patch
Dropped: zlib-off64_t.patch
a566e156b3kq
Because of the following commit ,
68034f837a
when we enable lib32, getting build failure because there is a check for target
support for "-Zdual-proc-macros" flag not functioning properly when lib32 is
enabled in the build environment. So for now reverting this commit and bring
back the previous behavior, where the "-Zdual-proc-macros" flag is always
added for building proc macros, regardless of the target architecture's support.
This would bypass the check introduced in the patch, allowing the build to
proceed without error, even when building for a 64-bit architecture with lib32 enabled.
(From OE-Core rev: 40d8dafdf556d7ce79c12a6de872193be9a0928a)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A new feature "Link std statically in rustc_driver" was introduced
in rust_1.82 [https://github.com/rust-lang/rust/pull/122362],and
which is causing the below failure in oe-selftest.
Running unittests src/main.rs (build/x86_64-unknown-linux-gnu/stage1-rustc/
x86_64-poky-linux-gnu/release/deps/rustc_main-92223b15c9f2d827)
uploaded ".../build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-poky-linux-gnu/
release/deps/rustc_main-92223b15c9f2d827", waiting for result
/tmp/work/test4056/rustc_main-92223b15c9f2d827: error while loading shared
libraries: librustc_driver-fb0866b1cd913c20.so: cannot open shared object file: No
such file or directory
The rustc_main binary depends on the librustc_driver-*.so file. However,
this file has not been copied to QEMU. If we manually copy the file into
QEMU and export the LD_LIBRARY_PATH, the issue does not occur. Issue
reprorted to upstream and reverted the buggy code as a workaround.
Upstream-Status: Inappropriate [reported at https://github.com/rust-lang/rust/issues/136237]
(From OE-Core rev: 977bd1a10771a6588e596e1bbfd49e9af659aa4a)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
