1.0.0-alpha.4 drops RUST_LIBC_UNSTABLE_MUSL_V1_2_3 resulting in stack corruption

[ninja-]

I am working on porting my project to RISCV32 and switched to latest alpha build seeing it fixes some RISCV32 compatibility issues I encountered.

export RUST_LIBC_UNSTABLE_MUSL_V1_2_3 = "1"
export RUST_LIBC_UNSTABLE_GNU_TIME_BITS = "64"

I've been using this for a long time on multiple platforms (ARM, MIPS) without issues so far, to get everything working with latest MUSL.

f08bfce this commit changes env names without any fallback, while providing fallback for GNU_TIME_BITS only.

It's a dangerous change because it causes silent stack corruption...I updated the env name in my project and the corruption is gone.

[tgross35]

If you're interested, a PR to add a warning on RUST_LIBC_UNSTABLE_MUSL_V1_2_3 (similar to RUST_LIBC_UNSTABLE_GNU_TIME_BITS) would be welcome - I meant to add one but guess I forgot.

We've been trying to keep these configs reasonably usable but just as a reminder, they are unstable - there are going to be sharp edges aside from this. (This change is also well-documented in the relnotes, https://github.com/rust-lang/libc/releases/tag/0.2.187)

[ninja-]

ah...that explains why changing back to non-alpha latest being 0.2.187 did not by itself remove corruption.
I am not sure if a warning is the right direction. I wouldn't even notice such a warning deep in my CI/CD logs.

Maybe auto detection? V1.2.3 added a symbol called qsort_r so a test could be made to detect it.

[tgross35]

0.2.x and alpha should be reasonably similar if you set those flags, alpha pretty much just has a few more things cleaned up already.

Sorry, I meant a warning plus the fallback - like for glibc we print RUST_LIBC_UNSTABLE_GNU_TIME_BITS will be removed ... but still use it for the time being. When it's been a couple releases and time to remove those we could also fail the build rather than basically quietly switching behavior, but I'll have to think about.

Auto detection doesn't work great libc itself since you don't need the C headers present to build, so you might get different compilation based on whether or not your local machine has musl available. We have a few instances of this, like detecting FreeBSD version, but that would actually be kind of nice to remove.

[ninja-]

I see. Well, I'll leave the final decision up to you, I'll just stay more careful in regularly checking if the env variable is still supported.

[tgross35]

For now I'm happy to take a PR adding a fallback+warning for that variable if you're interested, to match the GNU variables. I just don't plan on doing it myself.