Skip to content
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

WathOS CI broken #238

Closed
kali opened this issue Oct 14, 2024 · 6 comments · Fixed by #243
Closed

WathOS CI broken #238

kali opened this issue Oct 14, 2024 · 6 comments · Fixed by #243

Comments

@kali
Copy link
Collaborator

kali commented Oct 14, 2024

Hey @simlay, would you have an idea about what's wrong in there ? It looks like cargo tries to test proc-macros tests, which obviously wont work on a X-platform settings...

https://github.com/sonos/dinghy/actions/runs/11321297897

@fredszaq
Copy link
Collaborator

looks like this started with the nightly from october 5th, so probably something in there https://github.com/rust-lang/rust/commits/master/?since=2024-10-03&until=2024-10-05

there is this rust-lang/rust@d0a467a
that bumps cargo with these new changes rust-lang/cargo@80d82ca...ad074ab maybe something in there causing problems ? the interesting thing is that we don't see this on the regular builds for witch we also du runs using nightly toolchains

@simlay
Copy link
Contributor

simlay commented Oct 14, 2024

Huh. This is definitely weird. With the nightly-2024-10-05-aarch64-apple-darwin toolchain, things work as expected but with nightly-2024-10-06-aarch64-apple-darwin it fails with Library not loaded: @rpath/libstd-e61cddebfd02205d.dylib. Digging more into it, it's definitely failing on the "tests" (there is nothing in the src/lib.rs) oftest-proc-macro subcrate in the test-ws. I feel like there's a mild chance of rust-lang/rust#131016 might be the issue. @madsmtm might have some thoughts.

@madsmtm
Copy link
Contributor

madsmtm commented Oct 22, 2024

Hmm, I doubt that rust-lang/rust#131016 is the problem, like I noted there:

the difference is only observable if you manually unarchive the rlib (and the format of that is explicitly unspecified).

I'll try to get a proper rustc bisection going later today.

@madsmtm
Copy link
Contributor

madsmtm commented Oct 27, 2024

Took a while, but I found the culprit, it is rust-lang/rust#131188 - things work again if I copy the libstd-*.dylib file from /lib/rustlib/aarch64-apple-darwin/lib/libstd-*.dylib to /lib/libstd-*.dylib inside my toolchain installation (~/.rustup/toolchains/*-aarch64-apple-darwin).

I believe that PR is correct, and that Dinghy was wrong before to be relying on that file being available, though I'm not sure how to fix it?

@madsmtm
Copy link
Contributor

madsmtm commented Oct 27, 2024

It seems like Cargo is adding $HOME/.rustup/toolchains/*-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib to DYLD_FALLBACK_LIBRARY_PATH when running cargo test normally, but when using -Zbuild-std it for some reason isn't doing that.

The issue can be reproduced with just:

cd test-ws
cargo +nightly-2024-10-10 test -ptest-proc-macro --lib -Zbuild-std --target=aarch64-apple-darwin

@madsmtm
Copy link
Contributor

madsmtm commented Oct 27, 2024

I've opened rust-lang/cargo#14735, in the meantime I think the best thing that Dinghy can do is disable this test when using -Zbuild-std

fredszaq added a commit that referenced this issue Nov 18, 2024
this should fix #238 while we wait for a proper fix for
rust-lang/cargo#14735
@kali kali closed this as completed in #243 Nov 18, 2024
@kali kali closed this as completed in 3244bc9 Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants