Description
I built a debug version of llvm, clang and compiler-rt 20.1.5 on Windows.
I generated llvm IR for the following c++ program with clang.exe -S -emit-llvm ..\hello.cpp -o hello.ll
#include <iostream>
int main() {
std::cout << "Hello from lli-cpp!\n";
return 0;
}
When I try to run the program with lli while supplying the orcjit runtime, it fails to find a symbol when initializing the jitDylib.
PS C:\Users\hoisun\tools\llvm-project\build> .\bin\lli.exe --orc-runtime "C:\Users\hoisun\tools\llvm-project\build\lib\clang\20\lib\windows\orc_rt-x86_64.lib" --jit-linker jitlink hello.ll
C:\Users\hoisun\tools\llvm-project\build\bin\lli.exe: Symbols not found: [ __orc_rt_jit_dlopen_wrapper ]
I am quite certain that the symbol is inside the orc runtime, I can see it in the compiler-rt source and in dumpbin.exe.
The orc runtime (<Platform> jitDylib) is correctly added as part of the search order too, along with the other Windows runtime libraries.
The automatically detected VC toolchain path is correct, so it finds the libraries. We can be sure of that, because setting up the COFF executor platform already shows a lot of materialisation of STL symbols going on among __orc_rt_jit_xxx ones.
LLJIT running initializers for JITDylib "main"
Looking up { (__orc_rt_jit_dlopen_wrapper, RequiredSymbol) } in [ ("main", MatchAllSymbols), ("api-ms-win-crt-conio-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-convert-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-environment-l1-1-0.dll",
MatchExportedSymbolsOnly), ("api-ms-win-crt-filesystem-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-heap-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-locale-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-math-l1-1-0.dll",
MatchExportedSymbolsOnly), ("api-ms-win-crt-multibyte-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-process-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-runtime-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-stdio-l1-1-0.dll",
MatchExportedSymbolsOnly), ("api-ms-win-crt-string-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-time-l1-1-0.dll", MatchExportedSymbolsOnly), ("api-ms-win-crt-utility-l1-1-0.dll", MatchExportedSymbolsOnly), ("VCRUNTIME140.dll", MatchExportedSymbolsOnly),
("VCRUNTIME140_1.dll", MatchExportedSymbolsOnly), ("VCRUNTIME140_THREADS.dll", MatchExportedSymbolsOnly), ("MSVCP140.dll", MatchExportedSymbolsOnly), ("MSVCP140_1.dll", MatchExportedSymbolsOnly), ("MSVCP140_2.dll", MatchExportedSymbolsOnly),
("MSVCP140_ATOMIC_WAIT.dll", MatchExportedSymbolsOnly), ("MSVCP140_CODECVT_IDS.dll", MatchExportedSymbolsOnly), ("ntdll.dll", MatchExportedSymbolsOnly), ("Kernel32.dll", MatchExportedSymbolsOnly), ("<Platform>", MatchExportedSymbolsOnly), ("<Process Symbols>",
MatchExportedSymbolsOnly) ] (required state: Ready)
The problem what I found is that even though it starts the lookup as expected with Entering OL_applyQueryPhase1: Lookup kind: Static (which I think would find the missing symbol in the <Platform> jitDylib, because the StaticLibraryDefinitionGenerator for the orc runtime is added). After looking through main jitDylib and not finding anything, it hits the DLLImportDefinitionGenerator with switches the lookup in the rest of the jitDylibs to Entering OL_applyQueryPhase1: Lookup kind: DLSym. By the time it reaches the <Platform> jitDylib it will go through the static library generators (including the one for the orc runtime) but it returns early because K != LookupKind::Static.
I hope this is enough information, otherwise please let me know what is necessary. But because I only use the llvm tools from the same build it should be easy to reproduce.