Feedback-ID: ie0a040ee:Fastmail
Message-ID: <170e7e57-fe43-4e7e-8566-a96fcdf23075@eisentraut.org>
Date: Mon, 7 Apr 2025 18:38:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: Andres Freund <andres@anarazel.de>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
 Christoph Berg <myon@debian.org>, Tom Lane <tgl@sss.pgh.pa.us>,
 Bruce Momjian <bruce@momjian.us>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Daniel Gustafsson <daniel@yesql.se>, Thomas Munro <thomas.munro@gmail.com>,
 Nazir Bilal Yavuz <byavuz81@gmail.com>, Antonin Houska <ah@cybertec.at>
References: <A50E37E8-05A4-4406-945D-14C757AE4AD6@yesql.se>
 <Z9taYF0kIuv42N8e@momjian.us>
 <CAOYmi+kn+NYA=DNMZds8sPXonAFg3dJnTgQ+vsOMXsk1Yz+3Gg@mail.gmail.com>
 <Z9x_sUXIFz8rjvBN@momjian.us> <1120967.1742504934@sss.pgh.pa.us>
 <wbqaa72xxfnqtsspanbteoycmtpb6oshtwbrm7uwiw3pur4ll4@tybxmaasfjkv>
 <Z-qheTno9lYmjrJu@msg.df7cb.de>
 <CAOYmi+n+WB9fuQeoPL-0FWvC+fzJXUEfH=Ne1q7q5xT936TE=A@mail.gmail.com>
 <CAOYmi+moTsgohh5Tf1gn7dBynARV9EFfWaBVPcJD9O=h6RkSCw@mail.gmail.com>
 <5bec3d4f-613f-425b-88c4-59e71c70f7d6@eisentraut.org>
 <t66lxwxgaxinug7zr4pgf72anhzkqwgrudmqnczgjdu4rv3ll5@jkcxvyvkgcqc>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <t66lxwxgaxinug7zr4pgf72anhzkqwgrudmqnczgjdu4rv3ll5@jkcxvyvkgcqc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/170e7e57-fe43-4e7e-8566-a96fcdf23075%40eisentraut.org>
Precedence: bulk

On 07.04.25 16:43, Andres Freund wrote:
>>> While I was looking into this I found that Debian's going to use the
>>> existence of an SONAME to check other things, which I assume will make
>>> Christoph's life harder. I have switched over to
>>> 'libpq-oauth-<major>.so', without any SONAME or symlinks.
>> Yes, this is correct.  We want a shared module, not a shared library, in
>> meson parlance.
> It's not entirely obvious to me that we do want that.
> 
> There recently was a breakage of building with PG on macos with meson, due to
> the meson folks implementing a feature request to move away from using
> bundles, as
> 1) bundles apparently aren't supported on iOS
> 2) there apparently aren't any restrictions left that require using bundles,
>     and there haven't been for a while.
> 
> They've now reverted these changes, due to the postgres build failures that
> caused as well as recognizing they probably moved too fast, but the iOS
> portion seems like it could be relevant for us?

Um, interesting.  AFAICT, the change you mention was reverted from the 
1.7 branch because it was accidentally backpatched, but it remains in 
master.

(For those just catching up:

https://github.com/mesonbuild/meson/issues/14240
https://github.com/mesonbuild/meson/pull/14340
https://github.com/mesonbuild/meson/commit/fa3f7e10b47d1f2f438f216f6c44f56076a01bfc
)

Overall, this seems like a good idea, as it removes a historical 
platform-specific particularity.  (I found a historical analysis at 
<https://stackoverflow.com/questions/2339679/>.)

But it does break existing users that add -bundle_loader, because 
-bundle_loader only works with -bundle and is rejected with -dynamiclib.

To test, I patched the makefiles to use -dynamiclib instead of -bundle, 
which also required removing -bundle_loader, and it also required adding 
-Wl,-undefined,dynamic_lookup.  This built correctly and generally worked.

But then you also run into a new variant of this issue:

https://www.postgresql.org/message-id/E1o4HOv-001Oyi-5n@gemulon.postgresql.org

Because there is no -bundle_loader, the symbol search order appears to 
be different, and so hash_search() gets found in the OS library first.

So this is all going to be a mess at some point sooner or later. :-(


> Afaict this library doesn't have unresolved symbols, due to just linking to
> libpq. So I don't think we really need this to be a shared module?

Apart from the hard distinction on macOS, in terms of the build system, 
the distinction between "library" and "module" is mainly whether the 
resulting library gets a soname, version symlinks, and what directory it 
is installed in, so in that sense the discussion so far indicates that 
it should be a module.  I suppose on macOS we could link it like a 
library and install it like a module, but that would effectively create 
a third category, and I don't see why that would be worth it.