WathOS CI broken

[kali]

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]

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 https://github.com/rust-lang/rust/commit/d0a467a89f513c1eaef5e99cb446c66dc37c2837 that bumps cargo with these new changes https://github.com/rust-lang/cargo/compare/80d82ca22abbee5fb7b51fa1abeb1ae34e99e88a...ad074abe3a18ce8444c06f962ceecfd056acfc73 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]

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 https://github.com/rust-lang/rust/pull/131016 might be the issue. @madsmtm might have some thoughts.

[madsmtm]

Hmm, I doubt that https://github.com/rust-lang/rust/pull/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]

Took a while, but I found the culprit, it is https://github.com/rust-lang/rust/pull/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]

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]

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