Unify DLSUFFIX on Darwin
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.
Attachments:
0001-Unify-DLSUFFIX-on-Darwin.patchtext/plain; charset=UTF-8; name=0001-Unify-DLSUFFIX-on-Darwin.patchDownload+13-24
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
On 22.06.22 15:45, Tom Lane wrote:
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.
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.
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 22.06.22 15:45, Tom Lane wrote:
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.
Hm. Since we force people to recompile extensions for new major versions
anyway, maybe it'd be all right. I'm sure there is *somebody* out there
who will have to adjust their build scripts, but it does seem like it
shouldn't be much worse than other routine API changes.
[ thinks for a bit... ] Might be worth double-checking that pg_upgrade
doesn't get confused in a cross-version upgrade. A quick grep doesn't
find that it refers to DLSUFFIX anywhere, but it definitely does pay
attention to extensions' shared library names.
regards, tom lane
On 2022-06-24 Fr 10:13, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
On 22.06.22 15:45, Tom Lane wrote:
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.Hm. Since we force people to recompile extensions for new major versions
anyway, maybe it'd be all right. I'm sure there is *somebody* out there
who will have to adjust their build scripts, but it does seem like it
shouldn't be much worse than other routine API changes.[ thinks for a bit... ] Might be worth double-checking that pg_upgrade
doesn't get confused in a cross-version upgrade. A quick grep doesn't
find that it refers to DLSUFFIX anywhere, but it definitely does pay
attention to extensions' shared library names.
The buildfarm client uses `make show_dl_suffix` to determine filenames
to look for when seeing if an installation is complete. It looks like
that will continue to work.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 24.06.22 16:13, Tom Lane wrote:
[ thinks for a bit... ] Might be worth double-checking that pg_upgrade
doesn't get confused in a cross-version upgrade. A quick grep doesn't
find that it refers to DLSUFFIX anywhere, but it definitely does pay
attention to extensions' shared library names.
pg_upgrade just checks that it can "LOAD" whatever it finds in probin.
So this will work if extensions use the recommended extension-free file
names. If they don't, they should get a clean failure.
If this becomes a problem in practice, we could make pg_dump
automatically adjust the probin on upgrade from an old version.
I have committed this now. We can see how it goes.