Re: [PATCH] jit: fix build with LLVM-21 - Mailing list pgsql-hackers
From | Holger Hoffstätte |
---|---|
Subject | Re: [PATCH] jit: fix build with LLVM-21 |
Date | |
Msg-id | b3376d7f-93b1-765d-addf-2e09939d0f47@applied-asynchrony.com Whole thread Raw |
In response to | Re: [PATCH] jit: fix build with LLVM-21 (Peter Eisentraut <peter@eisentraut.org>) |
List | pgsql-hackers |
On 2025-09-12 08:36, Peter Eisentraut wrote: > 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. Excellent! Thanks for taking a look. This was my first post to pgsql-hackers and I wasn't sure if I had done something wrong. > [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. ;-) I knew this would come up since I pondered the same thing :D As you said, the existing code is not consistent, but I can switch this to let the new code appear first, if you prefer. A new patch is attached. > 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 constructornot 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 &)>') for2nd 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? I do not - I dropped the patch into my Gentoo package build for 17.6 and it has been working fine when building with gcc-15.2 and the jit part with clang-21.1.0. I also just rebuilt everything with clang-21.1.1 (no gcc) and also do not see the problem. This is on amd64 Linux. The following commit seems to be involved: https://github.com/postgres/postgres/commit/9044fc1d45a0212fd123bd8f364eac058f60fed7 which is also in my 17.6 tree. I verified that the new SectionMemoryManager.cpp is compiled without error. Since you're using homebrew I guess this is triggered by the __aarch64__ guard in src/include/jit/llvmjit_backport.h. Unfortunately this is as far as I can help with this. Please let me know if there is anything else I can do. cheers Holger
Attachment
pgsql-hackers by date: