Description of problem: Package rust-tokei fails to build from source in Fedora rawhide. Version-Release number of selected component (if applicable): 9.1.1-1.fc31 Steps to Reproduce: koji build --scratch f31 rust-tokei-9.1.1-1.fc31.src.rpm Additional info: This package is tracked by Koschei. See: http://apps.fedoraproject.org/koschei/package/rust-tokei Last successful build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1240451 Current build, where only i686 failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=34238751 BUILDSTDERR: error: linking with `cc` failed: exit code: 1 BUILDSTDERR: | BUILDSTDERR: = note: "cc" [...trimmed arguments...] BUILDSTDERR: = note: /usr/bin/ld: /builddir/build/BUILD/tokei-9.1.1/target/release/deps/libhandlebars-cbf3fa5b112da913.rlib(handlebars-cbf3fa5b112da913.handlebars.8lxzppfs-cgu.8.rcgu.o): in function `handlebars::registry::Registry::setup_builtins': BUILDSTDERR: /usr/share/cargo/registry/handlebars-1.2.0/src/registry.rs:116: undefined reference to `handlebars::helpers::helper_if::IF_HELPER' BUILDSTDERR: /usr/bin/ld: /usr/share/cargo/registry/handlebars-1.2.0/src/registry.rs:117: undefined reference to `handlebars::helpers::helper_if::UNLESS_HELPER' BUILDSTDERR: /usr/bin/ld: /builddir/build/BUILD/tokei-9.1.1/target/release/build/tokei-b80c0fc585eb7773/build_script_build-b80c0fc585eb7773: hidden symbol `_ZN10handlebars7helpers9helper_if9IF_HELPER17h94bc0b06c1b1df67E' isn't defined BUILDSTDERR: /usr/bin/ld: final link failed: bad value BUILDSTDERR: collect2: error: ld returned 1 exit status BUILDSTDERR: BUILDSTDERR: error: aborting due to previous error BUILDSTDERR: error: Could not compile `tokei`.
That last successful build used rust-1.33.0-2.fc31.i686 with llvm7.0-libs-7.0.1-4.fc31.i686. The failed build used rust-1.34.0-1.fc31.i686 with llvm-libs-8.0.0-5.fc31.i686. I can reproduce this locally with unpatched tokei sources, letting cargo download all dependencies, so that rules out a problem with our crate packaging. I successfully built it in F29 using rust-1.34.0-1.fc29.i686 and llvm-libs-7.0.1-4.fc29.i686. I also successfully built it with upstream rust-1.34.0, which has bundled LLVM 8. That was based on a release candidate of 8.0, but the current rust beta and nightly are based on LLVM 8.0.0 final, and they're also fine. Nothing in rust's LLVM patches look applicable to this, but there are a few places in rustc that change behavior when the bundled rustc is used. This one looks suspicious, and might need to be version-based instead: https://github.com/rust-lang/rust/blob/1.34.0/src/librustc_codegen_llvm/llvm_util.rs#L64-L73
> This one looks suspicious, and might need to be version-based instead: > https://github.com/rust-lang/rust/blob/1.34.0/src/librustc_codegen_llvm/llvm_util.rs#L64-L73 I've enabled that in the following PR, but it doesn't help this issue. https://github.com/rust-lang/rust/pull/60097 In fact, even a local build of upstream rust with its own LLVM still fails on this. I'm not sure what I'm doing differently than the official nightly builds...
This affects ffsend as well, and I suppose, any other binaries built by Rust.
It appears to be a problem with ThinLTO. I'll file an upstream bug with details as I investigate more. As a workaround, you can set "codegen-units = 1", either in the Cargo.toml "[profile.release]" section, or as "-Ccodegen-units=1" in env RUSTFLAGS or in .cargo/config "[build] rustflags". Note that rustflags are not combined -- env RUSTFLAGS is used first if present. FWIW, reducing codegen-units is often better for performance, at the expense of compilation time. Some crates already have this set in Cargo.toml, e.g. fd-find does.