[PATCH] cargo: Drop cargo wrapper to ensure successfull cargo builds in SDK

[PATCH] cargo: Drop cargo wrapper to ensure successfull cargo builds in SDK

[Yash.Shinde]

From: Yash Shinde <Yash.Shinde@windriver.com>

- The SDK uses a cargo wrapper that sets LD_LIBRARY_PATH to point to SDK target library directory.
  This wrapper was added to resolve library path errors by including libdir and base_dir paths
  in LD_LIBRARY_PATH for tumbleweed-ty-3 distro.
  (https://git.openembedded.org/openembedded-core/commit/?id=388e7cac9f90e79ce8c3c1683d8ee0f4df1bc907)

- But, a simple 'cargo build' in SDK env caused failures for certain crates due to
  undefined symbol and broken C compiler in SDK. Removing the cargo wrapper builds the crate
  successfully.

- With tumbleweed no longer being part of the tested distributions, drop the cargo wrapper that was
  previously added to address library loading issues on it.
  This resolves the errors seen with 'cargo build' in SDK env.

References:
Tumbleweed removal: https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=96e82ce670c02b166398500435c2df455b09b951
List of tested distros: https://git.yoctoproject.org/yocto-autobuilder2/tree/config.py?id=694d2a9bae523d9396b37da9cc6535a558e04d81#n168

Fixes [YOCTO #15579]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15579

Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
---
 meta/recipes-devtools/rust/cargo_1.81.0.bb | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/meta/recipes-devtools/rust/cargo_1.81.0.bb b/meta/recipes-devtools/rust/cargo_1.81.0.bb
index 123032cdf7..091ac3ae97 100644
--- a/meta/recipes-devtools/rust/cargo_1.81.0.bb
+++ b/meta/recipes-devtools/rust/cargo_1.81.0.bb
@@ -44,14 +44,6 @@ do_install () {
 	install -m 755 "${B}/target/${CARGO_TARGET_SUBDIR}/cargo" "${D}${bindir}"
 }
 
-do_install:append:class-nativesdk() {
-	# To quote the cargo docs, "Cargo also sets the dynamic library path when compiling
-	# and running binaries with commands like `cargo run` and `cargo test`". Sadly it
-	# sets to libdir but not base_libdir leading to symbol mismatches depending on the
-	# host OS. Fully set LD_LIBRARY_PATH to contain both to avoid this.
-	create_wrapper ${D}/${bindir}/cargo LD_LIBRARY_PATH=${libdir}:${base_libdir}
-}
-
 # Disabled due to incompatibility with libgit2 0.28.x (https://github.com/rust-lang/git2-rs/issues/458, https://bugs.gentoo.org/707746#c1)
 # as shipped by Yocto Dunfell.
 # According to https://github.com/rust-lang/git2-rs/issues/458#issuecomment-522567539, there are no compatibility guarantees between
-- 
2.43.0

Re: [OE-core] [PATCH] cargo: Drop cargo wrapper to ensure successfull cargo builds in SDK

[Richard Purdie]

On Tue, 2025-01-21 at 02:54 -0800, Yash Shinde via lists.openembedded.org wrote:
> From: Yash Shinde <Yash.Shinde@windriver.com>
> 
> - The SDK uses a cargo wrapper that sets LD_LIBRARY_PATH to point to SDK target library directory.
>   This wrapper was added to resolve library path errors by including libdir and base_dir paths
>   in LD_LIBRARY_PATH for tumbleweed-ty-3 distro.
>   (https://git.openembedded.org/openembedded-core/commit/?id=388e7cac9f90e79ce8c3c1683d8ee0f4df1bc907)
> 
> - But, a simple 'cargo build' in SDK env caused failures for certain crates due to
>   undefined symbol and broken C compiler in SDK. Removing the cargo wrapper builds the crate
>   successfully.
> 
> - With tumbleweed no longer being part of the tested distributions, drop the cargo wrapper that was
>   previously added to address library loading issues on it.
>   This resolves the errors seen with 'cargo build' in SDK env.
> 
> References:
> Tumbleweed removal: https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=96e82ce670c02b166398500435c2df455b09b951
> List of tested distros: https://git.yoctoproject.org/yocto-autobuilder2/tree/config.py?id=694d2a9bae523d9396b37da9cc6535a558e04d81#n168
> 
> Fixes [YOCTO #15579]
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=15579
> 
> Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
> ---
>  meta/recipes-devtools/rust/cargo_1.81.0.bb | 8 --------
>  1 file changed, 8 deletions(-)

Even if we're not testing on tumbleweed, there is an interaction issue
here and this interaction is going to come back and bite us with some
new combination of host and nativesdk glibc.

I'm therefore not convinced that simply removing this is a great idea,
we need to find a way to address the underlying issue.

Cheers,

Richard