Normally, this shouldn't happen. It can happen in exceptional circumstances, if the compiled output of a bitcode object file references symbols that weren't listed as undefined in the bitcode object file itself. This can at least happen in the following cases: - A custom SEH personality is set via asm() - Compiler generated calls to builtin helper functions, such as __chkstk, or __rt_sdiv on arm Both of these produce undefined references to symbols after compiling to a regular object file, that aren't visible on the level of the IR object file. This is only an issue if the referenced symbols are provided as LTO objects themselves; loading regular object files after the LTO compilation works fine. Custom SEH personalities are rare, but one CRT startup file in mingw-w64 does this. The referenced pesonality function is usually provided via an import library, but for WinStore targets, a local dummy reimplementation in C is used, which can be an LTO object. Generated calls to builtins is very common, but the builtins aren't usually provided as LTO objects (compiler-rt's builtins explicitly pass -fno-lto when building), and many of the builtins are provided as raw .S assembly files, which don't get built as LTO objects anyway, even if built with -flto. If hitting this unusual, but possible, situation, error out cleanly with a clear message rather than crashing.
29 KiB
29 KiB