Switch to lld makes difficult cdylib that is both a so and an executable

[izissise]

Code

I tried this code:

// Cargo.toml
[lib]
crate-type = ["cdylib"]

// build.rs
if os == "linux" {
    println!("cargo:rustc-link-arg=-Wl,-pie");
    println!("cargo:rustc-link-arg=/usr/lib/x86_64-linux-gnu/Scrt1.o");
    println!("cargo:rustc-link-arg=-Wl,--dynamic-linker=/lib64/ld-linux-x86-64.so.2");
    println!("cargo:rustc-link-arg=-Wl,--allow-multiple-definition"); // when compiling for tests
} else if os == "macos" {
    println!("cargo:rustc-link-arg=-Wl,-execute");
    println!("cargo:rustc-link-arg=-Wl,-e,_main");
    println!("cargo:rustc-link-arg=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/crt1.o");
}


// lib.rs
/// 🪄 dynlib become an executable!
/// Entrypoint linux
#[cfg(not(test))]
#[allow(clippy::similar_names, clippy::panic, reason = "standard")]
#[expect(unsafe_code, reason = "ffi")]
#[unsafe(no_mangle)]
pub extern "C" fn main(_argc: i32, _argv: *const *const i8, _env: *const *const i8) -> i32 {
    // optional: parse argv if you need them
    match exec_async() {
        Ok(()) => 0,
        Err(e) => panic!("{e}"),
    }
}

/// 🪄 dynlib become an executable!
/// Entrypoint macosx
#[cfg(not(test))]
#[allow(clippy::similar_names, reason = "standard")]
#[expect(unsafe_code, reason = "ffi")]
#[unsafe(no_mangle)]
pub extern "C" fn _main(argc: i32, argv: *const *const i8, env: *const *const i8) -> i32 {
    main(argc, argv, env)
}

I expected to see this happen:
In rust 1.89 with BFD linker this works great, I can do ./target/*/*.so and the .so behave like a normal executabe.

Instead, this happened:
In rust 1.90 with LLD linker this doesn't work anymore,
note: rust-lld: error: -shared and -pie may not be used together
after removing -pie flag it compiles, the .so has a _start symbol but it call to a null value

Version it worked on

It most recently worked on: 1.89

Version with regression

rustc --version --verbose:

rustc 1.90.0 (1159e78c4 2025-09-14)
binary: rustc
commit-hash: 1159e78c4747b02ef996e55082b704c09b970588
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.90.0
LLVM version: 20.1.8

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[tgross35]

I think you'll need to file an issue against lld if this is something that is reasonably expected to work. For that you should try to reduce this further to a single rustc invocation (no Cargo/build.rs), or better for the LLD issue tracker would be a repro in C that works with bfd but not lld.

You should be able to easily work around this for now by passing -Clinker-features=-lld in your build script.

[Kobzol]

Indeed, if you use custom linker flags and do some magic that might depend on the linker implementation, you'll either have to find a way to make it work with LLD, or opt out of it and use the system BFD linker.

[bjorn3]

Don't you also need -Wl,-e,_start on Linux to actually set the ELF entrypoint?