Re: meson: Add _static and _shared suffixes to the library names
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>
Date: 2025-08-12T16:27:40Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ci: windows: Stop using DEBUG:FASTLINK
- c42f2bdcdf7f 16.11 landed
- 3e6059cc70c0 17.7 landed
- 2de22b1ead3c 18.0 landed
- 66f8765c5331 19 (unreleased) landed
Jacob Champion <jacob.champion@enterprisedb.com> writes: > On Tue, Aug 12, 2025 at 8:46 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: >> The solution is changing the libraries' names [3]. Changing >> conflicting libraries' names is actually enough but I wanted to add >> _static and _shared suffixes to all of the libraries' names as I think >> this is more future proof. >> >> Any feedback would be appreciated. > Just as a kneejerk reaction, I think it'd be really strange if the > Meson version of libpq-oauth.a was named libpq-oauth_static.a on disk, > and clients had to figure out which build system was used in order to > link. This proposal seems utterly unacceptable from a client compatibility standpoint. Sure, we could get away with renaming purely internal things like boot_parser, but libpq? It won't do for the ecpg libraries either. > Is there a way to work around this problem in a way that affects Windows only? Even on Windows, the proposal is unacceptable. The build products have to remain the same as what they've been for decades. If meson is unable to build them, we can't use meson. But I imagine there is something you can do to persuade the newer version to do what it was doing before. regards, tom lane