rust-lang/rust · error

from rlib

Error message

from rlib

What it means

Raised by rustc_codegen_gcc's fat-LTO path when a serialized module being linked is a SerializedModule::FromRlib variant. The GCC backend has not implemented consuming rlib-embedded bitcode for fat LTO, so this code path panics with unimplemented! to signal an unsupported configuration rather than silently miscompiling.

Source

Thrown at compiler/rustc_codegen_gcc/src/back/lto.rs:236

        serialized_modules.sort_by(|module1, module2| module1.1.cmp(&module2.1));

        // We add the object files and save in should_combine_object_files that we should combine
        // them into a single object file when compiling later.
        for (bc_decoded, name) in serialized_modules {
            let _timer = prof
                .generic_activity_with_arg_recorder("GCC_fat_lto_link_module", |recorder| {
                    recorder.record_arg(format!("{:?}", name))
                });
            info!("linking {:?}", name);
            match bc_decoded {
                SerializedModule::Local(ref module_buffer) => {
                    module.module_llvm.lto_mode = LtoMode::Fat;
                    module
                        .module_llvm
                        .context
                        .add_driver_option(module_buffer.0.to_str().expect("path"));
                }
                SerializedModule::FromRlib(_) => unimplemented!("from rlib"),
                SerializedModule::FromUncompressedFile(_) => {
                    unimplemented!("from uncompressed file")
                }
            }
        }
        save_temp_bitcode(cgcx, &module, "lto.input");

        // Internalize everything below threshold to help strip out more modules and such.
        /*unsafe {
        let ptr = symbols_below_threshold.as_ptr();
        llvm::LLVMRustRunRestrictionPass(
            llmod,
            ptr as *const *const libc::c_char,
            symbols_below_threshold.len() as libc::size_t,
        );*/

        save_temp_bitcode(cgcx, &module, "lto.after-restriction");
        //}

View on GitHub (pinned to 7088e4b63a)

Solutions

1. Disable fat LTO for the GCC backend (-C lto=off or -C lto=thin if supported).
2. Rebuild the rlib dependencies with the GCC backend so they enter LTO as Local modules rather than FromRlib.
3. Track / contribute the missing FromRlib handling upstream in rustc_codegen_gcc.

Example fix

# before
RUSTFLAGS='-C linker-plugin-lto -C lto=fat' cargo build
# after
RUSTFLAGS='-C lto=off' cargo build

# In build scripts, detect the GCC backend + fat LTO and refuse early
import os, sys
flags = os.environ.get("RUSTFLAGS", "")
if "codegen-backend=gcc" in flags and ("lto=fat" in flags or "linker-plugin-lto" in flags):
    sys.exit("rustc_codegen_gcc does not support FromRlib fat LTO; use -C lto=off")

When it happens

Trigger: Building with -C linker-plugin-lto / fat LTO where one of the inputs reaches the back end as FromRlib, while using rustc_codegen_gcc (the GCC backend) instead of the default LLVM backend. The match arm at lto.rs:236 panics.

Common situations: Switching a project from the LLVM backend to the experimental GCC backend while leaving fat/cross-crate LTO enabled; depending on a precompiled rlib that the GCC backend would need to inline during LTO.

Related errors

• from uncompressed file
• not implemented
• not implemented
• archive member at offset {start} with size {} exceeds archiv
• {context}: {err}

AI-assisted analysis of rust-lang/rust@7088e4b63a (2026-08-10). Data as JSON: /api/errors/a8db0594d4287c94. Report an issue: GitHub.