Re: meson vs. llvm bitcode files

Hi,

Thanks for looking into this!

On Wed, 15 Jul 2026 at 15:10, Christoph Berg <myon(at)debian(dot)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