-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] rust fails to build ytop and librespot when cross compiling on host=target arch #4719
Comments
Reference to cross compiling with rust - |
Further investigation compiling the bottom package which is an an alternative to ytop (as ytop is deprecated) has the same issues. https://github.com/ClementTsang/bottom. |
librespot is not working too, at the buildbot it looks like it works perfect for everything besides generic |
From my reading around rustup - there is something missing in the target (ie the x86) is not using the tool chain. |
I think the fix is something around setting - rustc-link-search See: |
Rust is using the host compiler to create the In the Generic case host triple is equal target triple (both x86_64-unknown-linux-gnu). It is not possible to use different tool chains for this case. We do set up a GLIBC_2.32 tool chain but GLIBC_2.32 is not available in host system and the build-script-build binaries cannot be executed. I'm afraid this was only working by accident in the past. There seem only to be two ugly work arounds:
|
Rust issues are noted as:
they provide insight on potential workaround / fix. ideally the cross compile would actually force a cross-compile regardless of the triple. |
I'm seeing no solution for us. |
So a dirty workaround would be a host os that has the same glib version? |
Yes, I've already successful tested with a groovy docker build container. |
Well so even the latest rust version 1.50.0 is screwed? I tried to compile a recent versio of librsvg and ended with:
|
Possible fix for this in #9322. |
Given the LE package dos not build rustc compiler. This needs a little bit of help / testing (not a just trivial .patch file.) notes:
|
This is our current package.mk script so essentially a download of the binaries. Need to move that to a compile to get the patch included as I understand it. This is the code itself.
|
I think all you have to do is build cargo from source with my patch after installing the prebuilt toolchain with rustup. AFAIK rustup includes both rustc and cargo, you only need to replace cargo. |
Using @jameshilliard patch (it works) and the following script. It is possible to build x86_64 librespot on U18. It is a massive hack. But need to have cargo to build cargo. And the u18 cargo is not building cargo ... I’m not at all happy with this hack. But maybe some groundwork we can use to workaround the cross compile until @jameshilliard patch is mainlined? Remembering the background to the failure is that cargo does not honour target cross compile if host=target. This came about because the LE glibc was advanced of the buildhost gcc. here are the commits required to LE10 to get the below to work:
|
I have update rust to nightly, now that rust-lang/cargo#9322 has been merged, using these instructions. rust version 1.55.0-nightly (ce1d5611a 2021-06-18) @jameshilliard - Do we still need to wait on rust-lang/cargo#9532 before this will start working? Still getting the libraries from the cross not being referenced.
|
no Are you setting |
Thanks for the howto. Draft PR updated and it works 😎 - #5446 |
Describe the bug
On compiling ytop on master the cross compiler is not picking up the glibc.
I’m pretty sure the issue is that the build host Ubuntu 18.04 has not got libc 2.32 - though the cross compiler target should not need this.
To Reproduce
Steps to reproduce the behavior:
Execute the build for ytop
PROJECT=Generic ARCH=x86_64 scripts/build ytop
I have tried a few things to understand the cargo cross compile but to no avail.
E.g.
When hard setting LD LIBRARY PATH and checking with ldd - I get different unresolvable linking errors.
I have included the diff below for the Latest ytop, and have tried hard coding the library path in for cargo.
Informations
Log file
Additional context
The text was updated successfully, but these errors were encountered: