| Message ID | 20250321132502.2607941-2-Deepesh.Varatharajan@windriver.com |
|---|---|
| State | Accepted, archived |
| Commit | ab29b970ba7e08eabca92018d103af5f249ed2c5 |
| Headers | show |
| Series | [1/5] rust: Fix bloat issue in recent rust updates | expand |
On Fri, 21 Mar 2025 at 14:25, Varatharajan, Deepesh via lists.openembedded.org <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote: > > From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> > > When multilibs are enabled, rustc could not find dynamic libraries in the > lib64 directory due to the bootstrapping process searching in the lib > directory. This commit exports both lib and lib64 paths to ensure > correct library detection. What is creating and populating this lib64 directory then, and how does it decide that it should be named 'lib64'? Shouldn't either that, or the code that looks in 'lib' be fixed so they match each other? This looks like an incomplete fix, as it does not get to the bottom of the mismatch problem. Alex
On 2025-03-24 5:23 a.m., Alexander Kanavin via lists.openembedded.org wrote: > On Fri, 21 Mar 2025 at 14:25, Varatharajan, Deepesh via > lists.openembedded.org > <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote: >> From: Deepesh Varatharajan<Deepesh.Varatharajan@windriver.com> >> >> When multilibs are enabled, rustc could not find dynamic libraries in the >> lib64 directory due to the bootstrapping process searching in the lib >> directory. This commit exports both lib and lib64 paths to ensure >> correct library detection. > What is creating and populating this lib64 directory then, and how > does it decide that it should be named 'lib64'? Shouldn't either that, > or the code that looks in 'lib' be fixed so they match each other? > > This looks like an incomplete fix, as it does not get to the bottom of > the mismatch problem. FYI: This will block the 1.84 update until we understand the root cause. What happened in 1.84 that we need this change? ../Randy > Alex > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#213520):https://lists.openembedded.org/g/openembedded-core/message/213520 > Mute This Topic:https://lists.openembedded.org/mt/111827575/3616765 > Group Owner:openembedded-core+owner@lists.openembedded.org > Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On 24-03-2025 14:53, Alexander Kanavin 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 Fri, 21 Mar 2025 at 14:25, Varatharajan, Deepesh via > lists.openembedded.org > <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote: >> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> >> >> When multilibs are enabled, rustc could not find dynamic libraries in the >> lib64 directory due to the bootstrapping process searching in the lib >> directory. This commit exports both lib and lib64 paths to ensure >> correct library detection. > What is creating and populating this lib64 directory then, and how > does it decide that it should be named 'lib64'? Shouldn't either that, > or the code that looks in 'lib' be fixed so they match each other? > > This looks like an incomplete fix, as it does not get to the bottom of > the mismatch problem. > > Alex Sure Alex, I will investigate further. Deepesh
On 24-03-2025 23:18, Randy MacLeod wrote: > This will block the 1.84 update until we understand the root cause. > What happened in 1.84 that we need this change? The issue has existed before, but with the new commit (https://github.com/rust-lang/rust/commit/68034f837a39387e49fc7d7c5b088f5372a1127e) from Rust 1.83, an error has started occurring. The problem is that when multilibs are enabled, stage1/rustc can't find the lib*.so files in the lib directory, as they are now placed in the lib64 directory. To resolve this, we initially reverted that commit. However, with the current update, we removed that revert patch. To resolve this issue, we exported the LD_LIBRARY_PATH to include both lib and lib64. After doing so, the issue was resolved. Deepesh
On 24-03-2025 23:18, Randy MacLeod wrote: > On 2025-03-24 5:23 a.m., Alexander Kanavin via lists.openembedded.org > wrote: >> On Fri, 21 Mar 2025 at 14:25, Varatharajan, Deepesh via >> lists.openembedded.org >> <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote: >>> From: Deepesh Varatharajan<Deepesh.Varatharajan@windriver.com> >>> >>> When multilibs are enabled, rustc could not find dynamic libraries in the >>> lib64 directory due to the bootstrapping process searching in the lib >>> directory. This commit exports both lib and lib64 paths to ensure >>> correct library detection. >> What is creating and populating this lib64 directory then, and how >> does it decide that it should be named 'lib64'? Shouldn't either that, >> or the code that looks in 'lib' be fixed so they match each other? >> >> This looks like an incomplete fix, as it does not get to the bottom of >> the mismatch problem. > > FYI: > > This will block the 1.84 update until we understand the root cause. > What happened in 1.84 that we need this change? > > > ../Randy > > When multilibs are enabled, building Rust fails due to the following commit: https://github.com/rust-lang/rust/commit/68034f837a39387e49fc7d7c5b088f5372a1127e The issue occurs because stage1/rustc cannot find the dependent *.so files. This issue was addressed in the following commit: https://github.com/rust-lang/rust/commit/139d6ba054a1a4cc5fe64981ad46fd5547bd4916 Where the necessary library paths were passed before executing stage1/rustc. The fix has been implemented in rust-master, and the patch has been backported to our sources, which resolves the issue we're encountering. Additional testing is ongoing, and once completed, Will send the V2 shortly. Thanks, Deepesh > >> Alex >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#213520):https://lists.openembedded.org/g/openembedded-core/message/213520 >> Mute This Topic:https://lists.openembedded.org/mt/111827575/3616765 >> Group Owner:openembedded-core+owner@lists.openembedded.org >> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com] >> -=-=-=-=-=-=-=-=-=-=-=- >> > > -- > # Randy MacLeod > # Wind River Linux
diff --git a/meta/recipes-devtools/rust/files/revert-Zdual-proc-macros-additional-check.patch b/meta/recipes-devtools/rust/files/revert-Zdual-proc-macros-additional-check.patch deleted file mode 100644 index 58e77e4e6e..0000000000 --- a/meta/recipes-devtools/rust/files/revert-Zdual-proc-macros-additional-check.patch +++ /dev/null @@ -1,43 +0,0 @@ -rust: Fix build failure for v1.83 when lib32 enabled - -Because of the following commit , -https://github.com/rust-lang/rust/commit/68034f837a39387e49fc7d7c5b088f5372a1127e -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. - -Upstream-Status: Pending - -Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com> -diff --git a/src/bootstrap/src/core/builder.rs b/src/bootstrap/src/core/builder.rs -index 9ac0b0a01f..b1374042fb 100644 ---- a/src/bootstrap/src/core/builder.rs -+++ b/src/bootstrap/src/core/builder.rs -@@ -1701,21 +1701,8 @@ impl<'a> Builder<'a> { - // Build proc macros both for the host and the target unless proc-macros are not - // supported by the target. - if target != compiler.host && cmd_kind != Kind::Check { -- let error = command(self.rustc(compiler)) -- .arg("--target") -- .arg(target.rustc_target_arg()) -- .arg("--print=file-names") -- .arg("--crate-type=proc-macro") -- .arg("-") -- .run_capture(self) -- .stderr(); -- let not_supported = error -- .lines() -- .any(|line| line.contains("unsupported crate type `proc-macro`")); -- if !not_supported { -- cargo.arg("-Zdual-proc-macros"); -- rustflags.arg("-Zdual-proc-macros"); -- } -+ cargo.arg("-Zdual-proc-macros"); -+ rustflags.arg("-Zdual-proc-macros"); - } - } - } diff --git a/meta/recipes-devtools/rust/rust-source.inc b/meta/recipes-devtools/rust/rust-source.inc index 838544e089..59774e4794 100644 --- a/meta/recipes-devtools/rust/rust-source.inc +++ b/meta/recipes-devtools/rust/rust-source.inc @@ -7,7 +7,6 @@ SRC_URI += "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n file://oeqa-selftest-Increase-timeout-in-process-sigpipe-ru.patch;patchdir=${RUSTSRC} \ file://0001-src-core-build_steps-tool.rs-switch-off-lto-for-rust.patch;patchdir=${RUSTSRC} \ file://revert-link-std-statically-in-rustc_driver-feature.patch;patchdir=${RUSTSRC} \ - file://revert-Zdual-proc-macros-additional-check.patch;patchdir=${RUSTSRC} \ " SRC_URI[rust.sha256sum] = "7b11d4242dab0921a7d54758ad3fe805153c979c144625fecde11735760f97df" diff --git a/meta/recipes-devtools/rust/rust_1.83.0.bb b/meta/recipes-devtools/rust/rust_1.83.0.bb index aaf35692ab..ec1e7a683d 100644 --- a/meta/recipes-devtools/rust/rust_1.83.0.bb +++ b/meta/recipes-devtools/rust/rust_1.83.0.bb @@ -223,6 +223,9 @@ rust_runx () { oe_cargo_fix_env + # When multilibs are enabled, rustc can't find dynamic libraries in "lib64" because the bootstrapping process looks in "lib". To fix this, export both paths: + export LD_LIBRARY_PATH=${S}/build/${RUST_BUILD_SYS}/stage1/lib:${S}/build/${RUST_BUILD_SYS}/stage1/lib64:$LD_LIBRARY_PATH + python3 src/bootstrap/bootstrap.py ${@oe.utils.parallel_make_argument(d, '-j %d')} "$@" --verbose } rust_runx[vardepsexclude] += "PARALLEL_MAKE"