Re: meson vs. llvm bitcode files - Mailing list pgsql-hackers

From Nazir Bilal Yavuz
Subject Re: meson vs. llvm bitcode files
Date
Msg-id CAN55FZ26ohMftt20NUtVAxU8Feqjhz-jEfUvFKATYEaRR+xmqg@mail.gmail.com
Whole thread
In response to Re: meson vs. llvm bitcode files  (Christoph Berg <myon@debian.org>)
List pgsql-hackers
Hi,

Thanks for looking into this!

On Wed, 15 Jul 2026 at 15:10, Christoph Berg <myon@debian.org> wrote:
>
> thanks for picking this up. Missing LLVM bitcode support was the
> blocker for using meson in package builds. (And using the speedup from
> massive parallelization.)
>
> I've been using the v12 patch for a few days now for building the
> postgresql-20 snapshot packages on apt.postgresql.org. Afaict, it does
> the right thing even though "are the .bc files really used" is hard to
> test/tell.

You are right, I manually test them by editing the
'llvmjit_inline.cpp' file so I can see some logs.


> Initially I had problems with the "install" step because the way I
> used the Debian build machinery was calling "ninja install install-world".
> The duplicated action cause weird errors like "not a directory"
> because apparently it started two threads racing along. The problem
> went away when changing to "ninja install-world". This is likely not a
> bug in this patch, and possibly not even a meson/ninja bug, but
> perhaps noteworthy here.

I couldn't find an exact reference from the docs but it seems
'install' is just a specific target name, not a command. Then, like
you said; two targets (install and install-world) race with each other
and cause the problem you shared. I checked and this problem happens
without this patch too.


> Re: Nazir Bilal Yavuz
> > > +    <literal>postgresql-&majorversion;-llvm-jit-bitcode.pc</literal>.  It is
> > >
> > > Do we want to install these pc files even with -Dllvm=disabled?
> >
> > I think we want to install them as these pc files can be used for
> > building extensions.
>
> > This .pc file collects the cflags (in particular the include directories)
> > needed to compile server code, so that the LLVM JIT bitcode emission can
> > reuse them. It is versioned and intentionally scoped to JIT bitcode only,
> > since there is not yet agreement on a stable, general extension-build
> > interface.
>
> Maybe this is the place to start a standard? There will be no users if
> we are telling them not to use it. I'd just name it postgresql-$version-extension.pc.

I think this is a reasonable suggestion. v15 addresses this as another
commit (0004) for now to get feedback.


> $ cat /usr/lib/postgresql/20/lib/pkgconfig/postgresql-extension.pc
> prefix=/usr
> includedir=${prefix}/include/postgresql
> libdir=${prefix}/lib/x86_64-linux-gnu
>
> build_inc0=""
> src_inc0=""
> pkglibdir=${prefix}//usr/lib/postgresql/20/lib
> dir_mod=${pkglibdir}
> dir_data=${prefix}/share/postgresql/20/extension
> dir_include=${prefix}/include/postgresql/20/server/extension
> dir_doc=${prefix}//usr/share/doc/postgresql-doc-20/extension
> dir_bitcode=${prefix}//usr/lib/postgresql/20/lib/bitcode
> bindir=${prefix}/lib/postgresql/20/bin
>
> There are some "/usr" too much in there.

Fixed.


> Will test that next, thanks

Thanks!

v15 is attached.

--
Regards,
Nazir Bilal Yavuz
Microsoft

Attachment

pgsql-hackers by date:

Previous
From: Alex Masterov
Date:
Subject: Re: Unexpected behavior after OOM errors
Next
From: Matthias van de Meent
Date:
Subject: Re: Reduce cleanup lock contention on standby replay