From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unify DLSUFFIX on Darwin |
Date: | 2022-06-24 11:26:54 |
Message-ID: | f64debe0-0045-9a7b-6af8-6122cc6ce18d@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22.06.22 15:45, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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.
Extensions generally only load the module files using the extension-free
base name. And if they do specify the extension, they should use the
provided DLSUFFIX variable and not hardcode it. So I don't see how this
would be a problem.
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2022-06-24 11:44:07 | Re: CREATE TABLE ( .. STORAGE ..) |
Previous Message | Andrey Borodin | 2022-06-24 11:09:46 | Re: array_cat anycompatible change is breaking xversion upgrade tests |