unresolved symbol rdl_oom when compiling cdylib crate with no_global_oom_handling on pc-windows-msvc target

[wmmc88]

Full repro crate available here: https://github.com/wmmc88/minimal-repros/tree/no_global_oom_handling

I tried this code:

lib.rs

#![no_std]

extern crate alloc;

use core::alloc::{GlobalAlloc, Layout};

use alloc::{
    alloc::{alloc, dealloc},
    vec::Vec,
};

#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[global_allocator]
static ALLOCATOR: Allocator = Allocator;

pub struct Allocator;
unsafe impl GlobalAlloc for Allocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        unsafe { alloc(layout) }
    }

    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        unsafe { dealloc(ptr, layout) };
    }
}

pub fn foo() {
    let _v = Vec::<u32>::new();
}

Cargo.toml

[package]
name = "no_global_oom_handling-test"
version = "0.1.0"
edition = "2024"

[lib]
crate-type = ["cdylib"]

[dependencies]


[profile.dev]
panic = "abort"
# lto = "thin" # Requires at least thin lto or else error: error LNK2019: unresolved external symbol __rdl_oom referenced in function __rust_alloc_error_handler␍

[profile.release]
panic = "abort"
# lto = "thin" # Requires at least thin lto or else error: error LNK2019: unresolved external symbol __rdl_oom referenced in function __rust_alloc_error_handler␍

.cargo/config.toml

[build]
rustflags = [
  "--cfg",
  "no_global_oom_handling",
]

[unstable]
build-std = ["core", "alloc"]

I expected to see this happen: successful compilation

Instead, this happened:
On pc-windows-msvc target, this causes the following linker error:

error LNK2019: unresolved external symbol _RNvCs95KLPZDDxvS_7___rustc9___rdl_oom referenced in function _RNvCs95KLPZDDxvS_7___rustc26___rust_alloc_error_handler

Some important observations:

• enabling lto = "thin" causes the linker error to disappear
• this linker error does not happen when the crate is not a cdylib
• both x86_64-pc-windows-msvc and aarch64-pc-windows-msvc cause this error
• there is no error when compiling with x86_64-unknown-linux-gnu target

Meta

rustc --version --verbose:

rustc 1.87.0-nightly (1aeb99d24 2025-03-19)
binary: rustc
commit-hash: 1aeb99d248e1b0069110cb03c6f1dcc7b36fd7f3
commit-date: 2025-03-19
host: aarch64-pc-windows-msvc
release: 1.87.0-nightly
LLVM version: 20.1.0

[moxian]

@rustbot label: +O-windows-msvc +T-compiler +T-libs +A-linkage +A-allocators -needs-triage +requires-nightly +-Zbuild-std

[bjorn3]

I'm surprised this wasn't noticed earlier. The allocator shim unconditionally contains a reference from __rust_alloc_error_handler to __rdl_oom when no #[alloc_error_handler] is defined.

there is no error when compiling with x86_64-unknown-linux-gnu target

Windows unlike most targets doesn't use --gc-sections, so symbols are included in the binary even if they are not actually used and as such all imports they have are necessary too.

[ChrisDenton]

Windows unlike most targets doesn't use --gc-sections, so symbols are included in the binary even if they are not actually used and as such all imports they have are necessary too.

The linker requires referenced symbols to exist at link time but that doesn't necessarily mean they're actually put in the final binary.