Open giordano opened 2 years ago
@giordano I see that https://github.com/JuliaPackaging/BinaryBuilderBase.jl/issues/307 has been closed. Is this issue still relevant?
I see that https://github.com/JuliaPackaging/BinaryBuilderBase.jl/issues/307 has been closed. Is this issue still relevant?
We updated the Rust toolchain, but we're still using Rustup 1.24 for doing that, because of the problems outlined above: https://github.com/JuliaPackaging/Yggdrasil/blob/7f3f8a1bd526f964108c9e881f3e9d088fd155ac/0_RootFS/Rust/build_tarballs.jl#L18-L20
I see that JuliaPackaging/BinaryBuilderBase.jl#307 has been closed. Is this issue still relevant?
We updated the Rust toolchain, but we're still using Rustup 1.24 for doing that, because of the problems outlined above: https://github.com/JuliaPackaging/Yggdrasil/blob/7f3f8a1bd526f964108c9e881f3e9d088fd155ac/0_RootFS/Rust/build_tarballs.jl#L18-L20
@giordano Thanks for your prompt response! Since I wasn't in the Rustup team during that time, I guess I'd like to first make sure that the issue is still there. Would you mind trying again with the latest stable (v1.27.1)?
Also, GCC 8.1 (from 2018) being used in the linkage is very old even back in 2022... Does an upgrade to GCC changes anything? Or, does cargo zigbuild --target x86_64-unknown-linux-musl
fix it for you?
Finally, as hyperfine
is a well-known crate, I guess we can ping its maintainer(s) to see if they have encountered anything similar.
I can't easily check right now because I'll be quite busy with work over the next 2-3 weeks, but I wanted to comment on a bit:
Also, GCC 8.1 (from 2018) being used in the linkage is very old even back in 2022...
We generally purposefully use "old" GCC/binutils versions to to maximise compatibility: we produce generic binaries to be used by as many users as possible, using super new toolchains versions has a compatibility cost. Certainly when I'll get the time to get back to this issue I can try using newer toolchains for the sake of checking that, but that's beside the point: the main issue is that rustc is targeting the wrong platform during cross-compilation. And I seem to remember I didn't have that issue only with hyperfine, it was a generic issue with the Rust toolchain coming out of Rustup 1.25, hence why I opened this issue in Rustup, and not in Rustc nor hyperfine.
Thanks for taking the time to look into this.
@giordano I definitely want to make sure we can get you back onto a newer rustup. I guess the hard part here is that this feels like it's at the intersection of rustup itself and the compiler toolchain? It seems very surprising to me that changes in rustup can cause the kind of linking failures. Would it be feasible to bisect rustup changes between the working and first failing release?
Background
BinaryBuilder is a toolbox written in Julia which provides a sandbox environment to cross-compile packages for a variety of platforms and compilers, including Rust. The host platform in the environment is always
x86_64-linux-musl
, from which you can target all the other platforms using the cross-compilers provided by BinaryBuilder. The Rust toolchain is obtained with Rustup, you can find the full script at https://github.com/JuliaPackaging/Yggdrasil/blob/b5fef352621f293f0e0b1091cbe86135a3408277/0_RootFS/Rust/build_tarballs.jl.Description of the problem with the linker in cross-compilation
Everything worked fine with the toolchains obtained with Rustup v1.24.3, but after upgrading to Rustup v1.25.1 we started having problems with what seems to be a wrong selection of the linker. For example I have working toolchains for Rust v1.61.0 and v1.65.0 obtained with Rustup v1.24.3, but broken toolchains for the same versions of Rust when obtained with Rustup v1.25.1. This seems a good indication that something changed in Rustup (or something related to it) but the problem is independent from the specific version of Rust used.
More specifically on the issue we're encountering, when trying to cross-compile hyperfine for
x86_64-linux-gnu
I getDespite the fact that the Cargo config file indicates that the linker for
x86_64-unknown-linux-gnu
isx86_64-linux-gnu-cc
and the target platform is specified with both the environment variableCARGO_BUILD_TARGET
(which is exported) and the--target
option tocargo build
, Cargo usesx86_64-linux-musl-cc
to link object files compiled forx86_64-unknown-linux-gnu
, which of course leads to errors likeUnfortunately this isn't very easy to reproduce because there are no released versions of BinaryBuilder which provide the broken Rust toolchain, I discovered the issues by doing local tests before cutting a new release. If someone is willing to install Julia I can try provide lengthy instructions to try and reproduce this locally, but perhaps someone has a clue of what could lead to a wrong selection of the linker in cross-compilation, or what changed between Rustup v1.24.3 and v1.25.1.
In case someone wants to compare a working a non-working toolchain, here they are (remember that the host is
x86_64-linux-musl
):It's also totally possible that the script to obtain the toolchain has some problems, we are far from being experienced Rust developers, so any help with improving that would be appreciated, but I'd like to reiterate that things worked fine until Rustup v1.24.3, problems emerged with v1.25.1.