--strip-unneeded libc.a causes Rust programs compiled with -C target-feature=+crc-static to segfault on startup

[Xi Ruoyao]

On Wed, 2025-08-20 at 05:19 -0700, H.J. Lu wrote:
> On Wed, Aug 20, 2025 at 2:35 AM Xi Ruoyao via Binutils
> <binutils@sourceware.org> wrote:
> > 
> > Hi,
> > 
> > With the latest Glibc and Binutils release, we found stripping libc.a
> > with --strip-unneeded will cause any Rust programs compiled with -C
> > target-feature=+crc-static (i.e. linking against the static libc) to
> > segfault on startup.  To reproduce:
> > 
> > $ cat hw.rs
> > pub fn main() {
> >     println!("Hello, world.");
> > }
> > $ unshare -mr env PS1="(unshared ns)# " LC_ALL=C bash --norc
> > (unshared ns)# cp /usr/lib/libc.a /tmp
> > (unshared ns)# strip --strip-unneeded /tmp/libc.a
> > (unshared ns)# mount --bind /tmp/libc.a /usr/lib/libc.a
> > (unshared ns)# rustc hw.rs -C target-feature=+crt-static
> > (unshared ns)# ./hw
> > Segmentation fault         (core dumped) ./hw
> > (unshared ns)# gdb hw
> > (gdb) r
> > Starting program: /home/xry111/hw
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000000000000000 in ?? ()
> > (gdb) bt
> > #0  0x0000000000000000 in ?? ()
> > #1  0x00007ffff7f507a3 in _IO_doallocbuf ()
> > #2  0x00007ffff7f4d756 in _IO_new_file_underflow ()
> > #3  0x00007ffff7f4b313 in getdelim ()
> > #4  0x00007ffff7f169da in pthread_getattr_np ()
> > #5  0x00007ffff7ef28f6 in std::rt::lang_start_internal ()
> > #6  0x00007ffff7ed8911 in std::rt::lang_start ()
> > #7  0x00007ffff7ed8a45 in main ()
> > 
> > We are currently working the issue around by using --strip-debug instead
> > of --strip-unneeded, but this seems bizarre to me: shouldn't --strip-
> > unneeded just keep anything that the linker may "need" to create a
> > correct executable?  Or is Glibc or Rust std doing something so strange
> > that strip cannot really tell it's needed?
> > 
> > --
> > Xi Ruoyao <xry111@xry111.site>
> 
> Please open a binutils bug.

https://sourceware.org/bugzilla/show_bug.cgi?id=33300.

-- 
Xi Ruoyao <xry111@xry111.site>