-
Notifications
You must be signed in to change notification settings - Fork 365
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
Spurious glibc Version Error When Using Build Scripts #724
Comments
I can't replicate this with nightly 2022-05-26 on windows with the latest powerpc64 image (sha256:d52b1c1e2f0666cf8e244e890f8e6dfe1907e427e394de10d11c385ae728912c)
|
Running |
I'm getting this when I mix the nightly and stable toolchains for a given target. $ cross run --target armv7-unknown-linux-gnueabihf
Finished dev [unoptimized + debuginfo] target(s) in 0.11s
Running `/linux-runner armv7 /target/armv7-unknown-linux-gnueabihf/debug/hellopp`
Hello, world!
$ cross run +nightly --target armv7-unknown-linux-gnueabihf
Warning: using newer rustc `1.63.0-nightly (490324f7b 2022-05-26)` for the target. Current active rustc on the host is `rustc 1.61.0 (fe5b13d68 2022-05-18)`.
> Update with `rustup update`
Compiling hellopp v0.1.0 (/project)
error: failed to run custom build command for `hellopp v0.1.0 (/project)`
Caused by:
process didn't exit successfully: `/target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build` (exit status: 1)
--- stderr
/target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build)
/target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build)
/target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build)
/target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by /target/debug/build/hellopp-0a565c6e09d5b0ce/build-script-build) We might have to document this as a known issue. Thoughts @Emilgardis? |
I want to know why this happens. Is the build script not invalidated with different toolchains? |
Still not sure, it doesn't reproduce very frequently. I think it's the above, but it should be invalidated and most of the time it is. |
Required to patch cross-rs#724 without deleting the entire volume for persistent data volumes. A few changes were required: the entire `/cross` mount prefix must be owned by the user so `/cross/target` can be removed. Next, we use the full path to the mounted target directory, rather than the symlink, since `cargo clean` would just delete the symlink. Finally, we've added `cargo clean` to a list of known subcommands, and it only needs docker if we use a remote host.
Required to patch cross-rs#724 without deleting the entire volume for persistent data volumes. A few changes were required: the entire `/cross` mount prefix must be owned by the user so `/cross/target` can be removed. Next, we use the full path to the mounted target directory, rather than the symlink, since `cargo clean` would just delete the symlink. Finally, we've added `cargo clean` to a list of known subcommands, and it only needs docker if we use a remote host.
Required to patch cross-rs#724 without deleting the entire volume for persistent data volumes. A few changes were required: the entire `/cross` mount prefix must be owned by the user so `/cross/target` can be removed. Next, we use the full path to the mounted target directory, rather than the symlink, since `cargo clean` would just delete the symlink. Finally, we've added `cargo clean` to a list of known subcommands, and it only needs docker if we use a remote host.
CI is running into cross-rs/cross#724, which should be fixed if we clear the cache.
CI is running into cross-rs/cross#724, which should be fixed if we clear the cache.
Been trying to make a consistent reproduction of this but nothing seems to work to reproduce it. I think what we need to do is identify exactly when this happens, and then if there are any other workarounds aside from I've been trying to reproduce it with |
In my particular case, it happens when
Running cross on Github Actions, snippet attached;
Dependencies in Cargo.toml file;
EDIT:
using |
I'm not certain it is the same issue but I have a consistent and simple way to repro something like this Steps:
The second cross build will fail with:
I am running this on an Intel Mac with Docker Desktop with |
Prevent cross from considering the targets built for x86_64 fresh for aarch64. See: cross-rs/cross#724
I noticed that the order seems to matter. Building |
Building the whole project with `dotnet publish -c Release --os win` would fail with the message "glibc version 2.25 not found" this was related to caching problems while compiling the build script and a workaround is specifying a different target directory for each target that should be build. See also the following issues for more details about the problem: - cross-rs/cross#988 - cross-rs/cross#724
Unfortunately the follwing problem was reintroduced because the linux target was removed without checking if debug builds still worked. Issue: cross-rs/cross#724
Seeing if [this](cross-rs/cross#724 (comment)) is a quick fix so I can avoid any deeper debugging.
* Update nokogiri to version with support for apple silicon * Update gem dependencies to address spec failures running with Ruby 3 * Require ActiveRecordAdapter from spec that uses it * Add support for both x86_64 and arm64 linux architectures * Build both x86 and arm dynamic libraries for ruby * Use Ruby 2.6 as minimum tested version and 3.2 for all ruby-related tasks Rationale: 2.6.10 is what ships with macOS 14.0 even though support for it stopped in March of 2022 and 3.2 is the latest stable version. * Ensure the ruby libs are copied and available for testing * Bump solargraph and rubocop Disable new cops for existing violations * Update bundler to get rid of SPELL_CHECKERS warning * Do not suggest extensions * Simplify YARD docs for query method Add the host and bindings parameters so calls that contain them don't fail typecheck * Must use Ruby 2.4 in order to build the docs on main * Must use Ruby 2.4 in order to build the docs on main * Use .ruby-version instead of hard-coding the current ruby version in Github actions The rationale for this is from the way that docs diffing works. Both the base branch and the new branch need to be able to build using the version of Ruby supported by that branch. Without this change, when a PR is introduced that updates the target Ruby version, a followup PR will be required to update the github action for building the 'base' branch's version of the docs. With this change, github actions will choose the version of Ruby targeted by the branch it is trying to build * Clippy * Cargo fmt * Test * Try building aarch64 first Seeing if [this](cross-rs/cross#724 (comment)) is a quick fix so I can avoid any deeper debugging. * Keep shuffling the deck chairs * Revert "Test" This reverts commit 7feebd1. * Add 0.27.3 changelog * Bump version * Let's just release now instead --------- Co-authored-by: Gabe Jackson <17556281+gj@users.noreply.github.com>
Issue Description
When using build scripts, even if
rustc
changes (path or target),cargo
won't always do a full re-compile, and this can lead to spurious glibc errors. This is linked to rust-lang/cargo#10367 (comment). Since we change targets all the time, we're much more likely to cause this "feature" to manifest than standard builds.There's 2 solutions:
--target-dir path/to/x
).cargo clean
when the error appears.More detailed information and a robust workaround are found on the wiki.
Update
This seems to happen sporadically, with any mixing of toolchains or targets. The issue occurs sporadically when the toolchain changes, and seems to be related to #858 (comment). The solution seems to be running
cargo clean
(with the appropriate target dir), but there needs to be a better solution.Version Info
$ cross --version cross 0.2.1 (459e03e 2022-05-26) Warning: Falling back to `cargo` on the host. cargo 1.63.0-nightly (39ad1039d 2022-05-25)
Sample code to reproduce:
This should compile normally, however, we are unable to find the appropriate glibc version. This was detected while debugging #441.
The text was updated successfully, but these errors were encountered: