Thread: 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.
Attachment
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.