From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Unify DLSUFFIX on Darwin
In-reply-to: <bcc45f78-e3c3-8fb3-7c42-5371b48b5266@enterprisedb.com>
References: <bcc45f78-e3c3-8fb3-7c42-5371b48b5266@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Wed, 22 Jun 2022 13:12:21 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3336873.1655905520.1@sss.pgh.pa.us>
Date: Wed, 22 Jun 2022 09:45:20 -0400
Message-ID: <3336874.1655905520@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3336874.1655905520%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> macOS has traditionally used extension .dylib for shared libraries (used 
> at build time) and .so for dynamically loaded modules (used by 
> dlopen()).  This complicates the build system a bit.  Also, Meson uses 
> .dylib for both, so it would be worth unifying this in order to be able 
> to get equal build output.

> There doesn't appear to be any reason to use any particular extension 
> for dlopened modules, since dlopen() will accept anything and PostgreSQL 
> is well-factored to be able to deal with any extension.  Other software 
> packages that I have handy appear to be about 50/50 split on which 
> extension they use for their plugins.  So it seems possible to change 
> this safely.

Doesn't this amount to a fundamental ABI break for extensions?
Yesterday they had to ship foo.so, today they have to ship foo.dylib.

I'm not against the idea if we can avoid widespread extension
breakage, but that part seems like a problem.

			regards, tom lane