On 08.09.25 15:20, Holger Hoffstätte wrote:
I tried building against LLVM-21 and noticed that a function for symbol
lookup was renamed (without semantic changes), breaking the LLVM JIT.
The following patch fixes this by adding a version guard. It applies
equally
to both master and 17.6. Passes the test suite and verified on 17.6 with
the
jit example from the documentation.
I can confirm that this change seems correct. See [0] for reference.
[0]:
https://github.com/llvm/llvm-project/commit/d3d856ad84698fa4ec66177d00558b2f5b438d3b
As a small style request, I would flip the conditional around so that
the new code appears first. I see that we don't do this very
consistently in the existing code, but maybe we can start a new trend. ;-)
In my testing with LLVM 21, I'm getting an additional error:
../src/backend/jit/llvm/llvmjit_wrap.cpp:56:18: error: no matching
constructor for initialization of 'llvm::orc::RTDyldObjectLinkingLayer'
56 | return wrap(new llvm::orc::RTDyldObjectLinkingLayer(
| ^
57 | *unwrap(ES), [] { return
std::make_unique<llvm::backport::SectionMemoryManager>(nullptr, true); }));
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/homebrew/Cellar/llvm/21.1.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:58:3:
note: candidate constructor not viable: no known conversion from
'(lambda at ../src/backend/jit/llvm/llvmjit_wrap.cpp:57:16)' to
'GetMemoryManagerFunction' (aka
'unique_function<std::unique_ptr<RuntimeDyld::MemoryManager> (const
MemoryBuffer &)>') for 2nd argument
58 | RTDyldObjectLinkingLayer(ExecutionSession &ES,
| ^
59 | GetMemoryManagerFunction
GetMemoryManager);
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/homebrew/Cellar/llvm/21.1.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:37:16:
note: candidate constructor (the implicit copy constructor) not viable:
requires 1 argument, but 2 were provided
37 | class LLVM_ABI RTDyldObjectLinkingLayer
| ^~~~~~~~~~~~~~~~~~~~~~~~
I gather you're not seeing that?
