Code

Given a staticlib with the source:

#[unsafe(no_mangle)] pub extern "C" fn demo() -> f32 { let x : f32 = 1.1; x.ceil() } 

compiled as crate-type = ["staticlib"] and the C program:

#include <math.h> #include <stdio.h> float demo(); int main(int argc, char** argv) { float x = -1.2; printf("%f\n", ceilf(x)); printf("%f\n", demo()); return 0; } 

When linking the program like this: $(CC) main.o as-crate/target/debug/libas_crate.a -lm -o out/tgt-from-crate the resulting binary ends up using ceilf from compiler-builtins rather than libm.

I expected to see this happen: The binary should still get ceilf from libm, eg

$ nm -uD out/tgt-from-crate | grep ceilf || true U ceilf@GLIBC_2.2.5 

Instead, this happened: Instead, the ceilf symbol was satisfied by the matching symbol in compiler-builtins, and so the C call was surprise-migrated to a different implementation.

Version it worked on

1.86
rustc --version --verbose:

rustc 1.86.0 (05f9846f8 2025-03-31) binary: rustc commit-hash: 05f9846f893b09a1be1fc8560e33fc3c815cfecb commit-date: 2025-03-31 host: x86_64-unknown-linux-gnu release: 1.86.0 LLVM version: 19.1.7 

Version with regression

1.87
rustc --version --verbose:

rustc 1.87.0 (17067e9ac 2025-05-09) binary: rustc commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359 commit-date: 2025-05-09 host: x86_64-unknown-linux-gnu release: 1.87.0 LLVM version: 20.1.1 

Additional information

I suspect this is related to some work tracked in #137578. I also found out Chromium has already stumbled on this: https://issues.chromium.org/issues/419258012#comment5 and for them it caused observable behavior changes. Apologies for not catching this sooner - we hadn't upgraded compiler-builtins for a while and didn't notice until a couple of weeks ago. :(