Repository navigation
Using a shebang-less script as a linker doesn't work anymore on Linux #101511
Description
Activity
This would happen with anything using Command, right? Not just rustc/cargo.
Nominating for libs-api to consider whether we want to workaround this by implementing the re-execution ourselves; my feeling is no but it is a regression so I think worth asking.
It only happens when using libstd-*.so from the newer rustc builds, or when building with any rustc against an old glibc.
That is, if you build some random crate that uses Command with any version of rustc, the behavior depends on whether the libc used for the crate compile is < 2.15 or not, not whether rustc is 1.64 or not.
Reacted by Josh Stonerustc 1.64 itself is affected by the change because it's built with a newer glibc, while older versions of rustc were built with an older glibc.
Note that it might be worth reviewing what other functions from glibc used by rustc/cargo have changed and how, because there might be subtle changes like this hidden somewhere.
Ah, that makes sense. It seems likely that folks might bump their build environments to a newer glibc since we only support newer ones now, so I think I'll still leave this nominated, but it's good if it affects few users in practice.
T-compiler may want to do that checking as you suggest and consider a (temporary, perhaps with a future compat warning?) fallback, separately from any decisions by std.
10 remaining items
- added and removed
on Dec 14, 2022 Reassigning to the compiler team. We're not planning to change std::process::Command, but they might want to consider adding special handling in the compiler for this.
I don't think the compiler team should have a special case for this, unless there's some real-world use case that's affecting projects. @glandium, is there some case that's hitting the specific use case of a linker in practice, or is this a more theoretical concern or a concern about the behavior of
Commandin general?I don't remember on what I hit this specifically, but I did hit it on some existing code that was using a linker wrapper without a shebang. I can tell for sure it was not Firefox. At the very least, the behavior change should be called out.
WG-prioritization assigning priority (Zulip discussion).
Tagging for release notes, I feel the suggestion in the first comment makes sense.
@rustbot label -I-prioritize +P-low +release-notes
Triage: I don't think the compiler will be adding any special cases for this, and it's long past the release that would've corresponded to the relnotes here.
STR:
cargo new foocd fooecho exit 42 > linkerchmod +x linkerRUSTFLAGS="-Clinker=$PWD/linker" cargo +nightly buildActual result:
With 1.63:
This is a regression from #95026. What's going on is that before that merge, the linker was executed via
posix_spawnp@GLIBC_2.2.5, and after, it's executed viaposix_spawnp@GLIBC_2.15. The difference between the two is that the former retries executing through the shell when the execution first failed with ENOEXEC. This applies to anything the compiler or cargo would execute viastd::process::Command. The change inposix_spawnpbehavior in glibc comes from https://sourceware.org/bugzilla/show_bug.cgi?id=13134. It's probably for the better, but it should probably be highlighted in the release notes.