Missing symbols with thin LTO on x86_64-pc-windows-msvc

[jgallagher]

I tried this code:

use aho_corasick::AhoCorasick;
use std::os::raw::c_void;
use std::slice;

#[no_mangle]
pub unsafe extern "C" fn foobar(input: *const [u8; 1], len: usize) -> *mut c_void {
    let input = slice::from_raw_parts(input, len);
    Box::into_raw(Box::new(AhoCorasick::new_auto_configured(input))) as *mut c_void
}

with this Cargo.toml file:

[package]
name = "msvc-lto-thin-bug"
version = "0.1.0"
authors = ["John Gallagher <...@...com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[lib]
crate-type = ["staticlib"]

[dependencies]
aho-corasick = "0.7.6"

[profile.release]
lto = "thin"

I compiled this (successfully) with cargo build --release, which produced target/release/msvc_lto_thin_bug.lib. I then tried to compile this C program (foobar.c):

#include <stdint.h>
#include <stdlib.h>

extern void *foobar(uint8_t *input, size_t len);

int main() {
    foobar(NULL, 0);
    return 0;
}

via:

cl /EHsc foobar.c /link /LIBPATH:"target\\release" msvc_lto_thin_bug.lib

I expected to see this happen: The program linked (although it obviously wouldn't do anything useful).

Instead, this happened:

Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27032.1 for x64

Copyright (C) Microsoft Corporation.  All rights reserved.

 

foobar.c

Microsoft (R) Incremental Linker Version 14.16.27032.1

Copyright (C) Microsoft Corporation.  All rights reserved.

 

/out:foobar.exe

/LIBPATH:target\\release

msvc_lto_thin_bug.lib

foobar.obj

msvc_lto_thin_bug.lib(msvc_lto_thin_bug-71de79c7a20eef0b.aho_corasick.ca16895p-cgu.4.rcgu.o) : error LNK2019: unresolved external symbol __imp__ZN6memchr3x866memchr2FN17heb3e0819c48b999aE referenced in function _ZN92_$LT$aho_corasick..prefilter..RareBytesOne$u20$as$u20$aho_corasick..prefilter..Prefilter$GT$14next_candidate17h4213f95a13c94717E

msvc_lto_thin_bug.lib(msvc_lto_thin_bug-71de79c7a20eef0b.aho_corasick.ca16895p-cgu.4.rcgu.o) : error LNK2019: unresolved external symbol __imp__ZN6memchr3x867memchr22FN17h6467cf846ba6072fE referenced in function _ZN92_$LT$aho_corasick..prefilter..RareBytesTwo$u20$as$u20$aho_corasick..prefilter..Prefilter$GT$14next_candidate17h6c996abec2b916acE

msvc_lto_thin_bug.lib(msvc_lto_thin_bug-71de79c7a20eef0b.aho_corasick.ca16895p-cgu.4.rcgu.o) : error LNK2019: unresolved external symbol __imp__ZN6memchr3x867memchr32FN17he9d22c893759d6a0E referenced in function _ZN94_$LT$aho_corasick..prefilter..RareBytesThree$u20$as$u20$aho_corasick..prefilter..Prefilter$GT$14next_candidate17hb5e69dcd42a14727E

foobar.exe : fatal error LNK1120: 3 unresolved externals

Meta

I have no idea what I'm doing on Windows; this is a reproducer from investigating a Windows build problem on a project I primarily develop on Mac/Linux (neither of which exhibit any problems with the above example).

The missing symbol demangles to __imp_memchr::x86::memchr3::FN::..., which I believe is an always inlined function in the memchr crate?

rustc --version --verbose:

rustc 1.43.0 (4fb7144ed 2020-04-20)
binary: rustc
commit-hash: 4fb7144ed159f94491249e86d5bbd033b5d60550
commit-date: 2020-04-20
host: x86_64-pc-windows-msvc
release: 1.43.0
LLVM version: 9.0

I tried the current (2020-04-29) nightly and got the same results.

[jgallagher]

Forgot to note - turning lto off or setting it to fat did not have the same error.