Repository navigation
LTO and no_builtins: undefined references to standard Rust symbols errors at link time #72140
Description
Activity
Inspired by discussion on PR #109821, I made a variant test case (largely taken from @dianqk's "stable" demo for that PR, to find out the historical behavior of Rust on that example. (The main differences are that 1. I changed the test to use
extern crate, in order to be able to build on older versions of Rust, 2. I changed it to uselto = truerather thanlto = fat, again for backward compatibility with older versions of Rust, and 3. I had the code start returning a non-()value from the linked crate, specially a&'static str, so that I could double-check that the dynamic behavior is plausible.)Here is the main thing I've discovered so far: Rust 1.0 through 1.12 were able to compile and run the adapted example. It was back in Rust 1.13 that we started seeing this incompatbility between LTO and
#![no_builtins], i.e. something along the lines of of:% cargo +1.13 build --release Compiling bar v0.1.0 (file:///home/ubuntu/Dev/Rust/Linking/issue_72140/rust-109821-reproducible/stable/bar) Compiling foo v0.1.0 (file:///home/ubuntu/Dev/Rust/Linking/issue_72140/rust-109821-reproducible/stable/foo) Compiling tool v0.1.0 (file:///home/ubuntu/Dev/Rust/Linking/issue_72140/rust-109821-reproducible/stable) error: linking with `cc` failed: exit code: 1 | = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/ubuntu/.rustup/toolchains/1.13-x86_64-unknown-linux-gnu/lib/rustlib/x86_6\ 4-unknown-linux-gnu/lib" "/home/ubuntu/Dev/Rust/Linking/issue_72140/rust-109821-reproducible/stable/target/release/tool.0.o" "-o" "/home/ubuntu/De\ v/Rust/Linking/issue_72140/rust-109821-reproducible/stable/target/release/tool" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/ubuntu/Dev\ /Rust/Linking/issue_72140/rust-109821-reproducible/stable/target/release/deps" "-L" "/home/ubuntu/.rustup/toolchains/1.13-x86_64-unknown-linux-gnu\ /lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/tmp/rustc.C74lmNfGlWwA/libfoo.rlib" "/tmp/rustc.C74lmNfGlWwA/libstd-a4\ 729905.rlib" "/tmp/rustc.C74lmNfGlWwA/liballoc_jemalloc-a4729905.rlib" "/tmp/rustc.C74lmNfGlWwA/libcompiler_builtins-a4729905.rlib" "-l" "dl" "-l"\ "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" = note: /usr/bin/ld: /tmp/rustc.C74lmNfGlWwA/libfoo.rlib(foo.0.o): in function `foo::msg': foo.cgu-0.rs:(.text._ZN3foo3msg17hb7b968140369922eE+0x1): undefined reference to `bar::msg' collect2: error: ld returned 1 exit statusSo, this has been broken for a long time (i.e. since the end of 2016), but it hasn't "always" been broken.
Oh, was PR #35637 the reason that this broke between 1.12 and 1.13?
Yes. The symbols required by
#![no_builtins]are present in LTO, but they are not exported. #109821 is a possible solution.
However, now I have found a more suitable solution, which is to let#![no_builtins]participate in LTO again.WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-medium
It seems that depending on a Rust library that has the attribute
#![no_builtins]prevents the linker to provide the needed symbols to the library.I made a repository to demonstrate this issue with a minimal reproduction case: Deluvi/bug-no-builtins-lto-rust. The instructions to run the example are in the README.
Here is an example error line (you can find the whole
cargooutput in the "Error output" drop down below):If you want the compilation to work, you can remove the `#![no_builtins] line and the compilation will work just fine.
Meta
rustc --version --verbose:Error output