In HarfBuzz we use cargo to build a staticlib, then link it to harfbuzz using meson. We use lto="fat" and that's essential to the performance of the generated rust code binary.
This used to work with gcc as the final linker with rustc 1.91.0-nightly (898aff7 2025-08-14), but after updating to rustc 1.91.0-nightly (51ff895 2025-09-02), now the generated libharfbuzz_rust.a includes: a harfbuzz_rust .o file that is an ELF binary, but also a compiler_builtins .o that is in LLVM IR bitcode. This makes the gcc linker fail linking with unknown file format error. Is this intentional?
Meta
rustc --version --verbose:
rustc 1.91.0-nightly (51ff89506 2025-09-02)
binary: rustc
commit-hash: 51ff895062ba60a7cba53f57af928c3fb7b0f2f4
commit-date: 2025-09-02
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0
In HarfBuzz we use cargo to build a staticlib, then link it to harfbuzz using meson. We use lto="fat" and that's essential to the performance of the generated rust code binary.
This used to work with gcc as the final linker with rustc 1.91.0-nightly (898aff7 2025-08-14), but after updating to rustc 1.91.0-nightly (51ff895 2025-09-02), now the generated libharfbuzz_rust.a includes: a harfbuzz_rust .o file that is an ELF binary, but also a compiler_builtins .o that is in LLVM IR bitcode. This makes the gcc linker fail linking with unknown file format error. Is this intentional?
Meta
rustc --version --verbose: