`x86_64-unknown-linux-musl` with `-Ctarget-feature=-crt-static` links to glibc

tested with rustc stable 1.83.0, on Arch Linux (kernel 6.6.69 LTS)

rustup install stable-x86_64-unknown-linux-gnu
rustup target add x86_64-unknown-linux-musl
cargo new musl-hm
cd musl-hm
cargo rustc --target x86_64-unknown-linux-musl -- -Ctarget-feature=-crt-static
ldd target/x86_64-unknown-linux-musl/debug/musl-hm
        linux-vdso.so.1 (0x00007ffc176a7000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000755e74d12000)
        libc.so.6 => /usr/lib/libc.so.6 (0x0000755e74b21000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x0000755e74dc4000)

The same thing happens with cargo build and RUSTFLAGS instead of cargo rustc.
This happens irrespective of whether a the musl system package is installed or not.

If you set target.x86_64-unknown-linux-musl.linker = "musl-gcc" then linking fails with -Ctarget-feature=-crt-static (complains about missing libgcc_s), and without -Ctarget-feature, the resulting binary crashes instantly (that's a duplicate of https://github.com/rust-lang/rust/issues/95926), but is dynamically linked to the musl library and loader.

I think rustc should error out on musl targets if attempting to disable crt-static, since anything else produces wrong or broken binaries. If the idea is that -crt-static works on targets where musl is the system libc (e.g. Alpine), then perhaps there should be something that detects whether the system libc is musl, and errors (or ignores crt-static) if not.

Start with the reported cargo rustc and cargo build reproducer for x86_64-unknown-linux-musl using -Ctarget-feature=-crt-static, then inspect the resulting binary with ldd. Compare behavior with and without the musl-gcc linker and verify the chosen handling of crt-static, including a clear error or a correctly linked executable.