On Wed, Nov 8, 2023 at 8:13 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> On 2023-Nov-08, Thomas Munro wrote:
> > On Wed, Nov 8, 2023 at 4:46 AM Alvaro Herrera <alvhe...@alvh.no-ip.org>
> > wrote:
> > > On 2023-Aug-25, Daniel Westermann (DWE) wrote:
> > >
> > > Yeah, I get this one too. I thought commit 37d5babb5cfa ("jit: Support
> > > opaque pointers in LLVM 16.") was going to silence it, but I was quite
> > > mistaken. I gave that code a quick look and could not understand what
> > > it was complaining about. Is it a bug in the LLVM headers?
> >
> > I found the commit where they fixed that in 15+:
> >
> > https://github.com/llvm/llvm-project/commit/1d9086bf054c2e734940620d02d4451156b424e6
> >
> > They don't seem to back-patch fixes, generally.
>
> Ah yeah, I can silence the warning by patching that file locally.
Since LLVM only seems to maintain one branch at a time as a matter of
policy (I don't see were that is written down but I do see for example
their backport request format[1] which strictly goes from main to
(currently) release/17.x, and see how the commit history of each
release branch ends as a new branch is born), I suppose another angle
would be to check if the Debian maintainers carry extra patches for
stuff like that. They're the ones creating the dependency on an 'old'
LLVM after all. Unlike the RHEL/etc maintainers' fast rolling version
policy (that we learned about in the thread for CF #4640). Who wants
to ship zombie unmaintained code for years? On the other hand, Debian
itself rolls faster than RHEL.
[1] https://llvm.org/docs/GitHub.html
