--crate-type=bin causes no_mangle symbols to be ommitted.

[lolbinarycat]

I tried this code:

fn main() {}

#[no_mangle]
extern "C" fn somefunction() {}

I expected to see this happen: the outputted ELF binary should contain a symbol named "somefunction".

Instead, this happened: rustc --crate-type=bin rustc-bug.rs && objdump -t rustc-bug | grep somefunction returned zero results.

Meta

rustc --version --verbose:

rustc 1.76.0 (07dca489a 2024-02-04) (built from a source tarball)
binary: rustc
commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
commit-date: 2024-02-04
host: x86_64-unknown-linux-gnu
release: 1.76.0
LLVM version: 17.0.6

[lolbinarycat]

here's the documentation that makes me believe this behavior is unintentional: https://doc.rust-lang.org/reference/abi.html

i ran into this problem when disassembling a program, but it could also cause issues for some dynamic libraries that expect the program that links against them to define some symbol for configuration.

workaround is to make sure that function is referenced from somewhere else in the program.

[eggyal]

The function is unused/dead code, so it's not being codegen'd (this has nothing to do with no_mangle: it'd be the same for any function). Perhaps you want it to be pub in a library crate?

[workingjubilee]

@lolbinarycat A close examination of the page you reference suggests its definition of "object file" excludes linked binaries, so this does seem to be "working as intended" currently, though the reference is confusingly written on this point.

[bjorn3]

You need the unstable -Zexport-executable-symbols to export symbols from an executable.

[saethlin]

I don't think there is a bug here; the current behavior is intentional; we have a flag to get the behavior that OP wants. I'd be quite surprised if we decide the default behavior is to export such symbols.