Feedback-ID: id4a34324:Fastmail
Date: Wed, 1 Apr 2026 09:19:34 -0400
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: meson vs. llvm bitcode files
Message-ID: <3whtmw6twe442o3r44gsagheq5cs2clcghzjeo7rljstpdemrh@oojczkhk2mbt>
References: 
 <CA+hiPX9ZHrryqFnMWfEZhqS4fLj2yv_shBR=cW07WXnSrDu8jA@mail.gmail.com>
 <CAN55FZ1fWtTpcL3ytJioZWt78oMsCyV5ivKho-pO-EJzvQSWXQ@mail.gmail.com>
 <CAN55FZ3oT2FUbd-Zga0w69gyv05ZtihKTypyJWH4JHL-nmv-kA@mail.gmail.com>
 <CAN55FZ3CN09j5o3PDw8wkiEqc4tt=7+VFwYriY451y=-9SN33A@mail.gmail.com>
 <CAN55FZ2vp2wuzMZVxzFqj=6wbSSs_REYFLbPJK9CaY2SHJTY=A@mail.gmail.com>
 <CAN55FZ138OBEehyxD1FKySMxKFteqf_VOR8LBkz-055YGU12rg@mail.gmail.com>
 <CAN55FZ3HTYjtooYWtGGhDQnSJWqPJmC+wszLGvnK36LwgC2uQA@mail.gmail.com>
 <4286824f-40c3-4716-ad71-2085b83f3736@eisentraut.org>
 <CAN55FZ0KxMphg+M+4Shm=HmNV+XhC7LUKc6hrC+-QiovhzvdVA@mail.gmail.com>
 <c6b26dee-bd62-44d9-b4f3-730b6ecf95c6@eisentraut.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c6b26dee-bd62-44d9-b4f3-730b6ecf95c6@eisentraut.org>
Archived-At: 
 <https://www.postgresql.org/message-id/3whtmw6twe442o3r44gsagheq5cs2clcghzjeo7rljstpdemrh%40oojczkhk2mbt>
Precedence: bulk

Hi,

On 2026-03-31 09:43:11 +0200, Peter Eisentraut wrote:
> On 18.03.26 13:44, Nazir Bilal Yavuz wrote:
> > > The comment that introduces postgresql-extension-warnings.pc says
> > > 
> > > +# Extension modules should likely also use -fwrapv etc. But it it's a
> > > bit odd
> > > +# to expose it to a .pc file?
> > > 
> > > but then -fwrapv ends up in postgresql-extension.pc anyway.  Not sure
> > > what was intended here.
> > 
> > I asked Andres off-list and Andres said that we need to have these
> > flags inside the .pc file but it is not very nice since these flags
> > (-fwrapv for example) change the behavior. Maybe Andres could clarify
> > this better.
> 
> Yes, it's probably right that extensions should build with the -f options
> that the server uses.  You probably need -fwrapv and -fno-strict-aliasing at
> least.  Then again, we don't know which compiler will consume the .pc file
> and whether it even supports these options in that particular spelling.

At the moment you can't really build server extensions against a postgres
built with a different compiler. E.g. building extensions with clang against a
server built with gcc triggers hundreds of warnings.  We just do too many
detections at configure time to make that reliably work.

I don't think this is a meson specific problem...


> > > The Requires list in my case is for example
> > > 
> > > Requires: krb5-gssapi, icu-uc, icu-i18n, ldap, libxml-2.0 >=  2.6.23,
> > > liblz4, openssl, zlib, libzstd >= 1.4.0
> > > 
> > > but I don't think these are actually required for building extensions
> > > (unless a particular extension directly makes use of one of them, in
> > > which case they should declare that on their own).
> > 
> > It seems that is how meson pkgconfig.generate() handles the
> > dependencies, please see [1]:
> > 
> > ...
> > * Dependencies provided by pkg-config are added into Requires: or
> > Requires.private:. If a version was specified when declaring that
> > dependency it will be written into the generated file too.
> > ...
> 
> Sure, but that doesn't make it right. ;-)  It would be a quite a regression
> if extensions switched to using this .pc file (which we would want them to
> eventually), and then building an extension would require installing all
> these -dev packages.

I'm pretty confused - isn't what meson does the only reasonable thing? You
can't reliably build an extension without having all the dependencies that the
server was built against also installed, because we have headers that include
the dependencies. If you e.g. don't have openssl or kerberos installed any
[indirect ]include of libpq-be.h will fail.

I don't understand how this would be a regression.

And adding these dependencies to eitehr Requires or Requires.private seems
pretty much required to ever get static linking to work.

Greetings,

Andres Freund