Linking Rust binaries against C libraries leads to weird link errors

[gfxstrand]

Describe the bug
This can happen when you have a C library which depends something from libc or something else that the C compiler would link in automatically and you then link a Rust binary against that C library. In Mesa, we saw it show up as undefined reference to '__aarch64_cas4_sync' errors when building certain unit tests against aarch64 (https://gitlab.freedesktop.org/mesa/mesa/-/issues/11632). I've also seen it show up as a undefined reference to 'atexit'. In both cases in Mesa, the C libraries were static libs. I have no idea if it can come up with dynamic linking.

To Reproduce
Unfortunately, this is can be really annoying to reproduce reliably. I was never able to reproduce the aarch64 Mesa issue in Mesa CI, even though both the bug reporter and our CI build on Debian. I suspect the atexit one is probably easier to reproduce but that issue showed up in a coworker's build, not mine. (I never pulled their branch and tried to build it so IDK if it would have reproduced for me.)

Workaround
The current workaround is to set rust_args: ['-C', 'default-linker-libraries'] in the binary. This gets us going again in Mesa but it feels like a hack.

[eli-schwartz]

I think it's probably correct and we should pass it by default.

Rust has an ideological thing where it links with -nodefaultlibs because they idk, want to prove that they can reimplement all link logic the hard way? Guarantee that rust isn't doing anything "unnecessary"?

This obviously falls over in a million pieces if you use C code anywhere and have anything even vaguely interesting. They added the default-linker-libraries option specifically with the comment that the default behavior is ideological rather than semantically correct, and that people "should be able to opt out of the ideology when they discover it doesn't work".

[eli-schwartz]

See:

rust-lang/rust#54675 (comment)
#12877
rust-lang/rust#54237