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
From 291defe5f2aed76c608de3894d131eafa3eaf761 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Wed, 22 Jun 2022 13:04:23 +0200
Subject: [PATCH] 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.
---
config/python.m4 | 15 +++++----------
configure | 15 +++++----------
src/Makefile.shlib | 2 --
src/makefiles/Makefile.darwin | 2 +-
src/template/darwin | 2 ++
5 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/config/python.m4 b/config/python.m4
index e500873ff3..b295ad3d3a 100644
--- a/config/python.m4
+++ b/config/python.m4
@@ -120,16 +120,11 @@ else
found_shlib=0
for d in "${python_libdir}" "${python_configdir}" /usr/lib64 /usr/lib
do
- # Note: DLSUFFIX is for loadable modules, not shared
- # libraries, so cannot be used here portably. Just
- # check all known possibilities.
- for e in .so .dll .dylib .sl; do
- if test -e "$d/lib${ldlibrary}$e"; then
- python_libdir="$d"
- found_shlib=1
- break 2
- fi
- done
+ if test -e "$d/lib${ldlibrary}${DLSUFFIX}"; then
+ python_libdir="$d"
+ found_shlib=1
+ break 2
+ fi
done
# Some platforms (OpenBSD) require us to accept a bare versioned shlib
# (".so.n.n") as well. However, check this only after failing to find
diff --git a/configure b/configure
index 7dec6b7bf9..f8306a2999 100755
--- a/configure
+++ b/configure
@@ -10570,16 +10570,11 @@ else
found_shlib=0
for d in "${python_libdir}" "${python_configdir}" /usr/lib64 /usr/lib
do
- # Note: DLSUFFIX is for loadable modules, not shared
- # libraries, so cannot be used here portably. Just
- # check all known possibilities.
- for e in .so .dll .dylib .sl; do
- if test -e "$d/lib${ldlibrary}$e"; then
- python_libdir="$d"
- found_shlib=1
- break 2
- fi
- done
+ if test -e "$d/lib${ldlibrary}${DLSUFFIX}"; then
+ python_libdir="$d"
+ found_shlib=1
+ break 2
+ fi
done
# Some platforms (OpenBSD) require us to accept a bare versioned shlib
# (".so.n.n") as well. However, check this only after failing to find
diff --git a/src/Makefile.shlib b/src/Makefile.shlib
index 551023c6fb..d0ec325bf1 100644
--- a/src/Makefile.shlib
+++ b/src/Makefile.shlib
@@ -118,7 +118,6 @@ endif
ifeq ($(PORTNAME), darwin)
ifdef soname
# linkable library
- DLSUFFIX = .dylib
ifneq ($(SO_MAJOR_VERSION), 0)
version_link = -compatibility_version $(SO_MAJOR_VERSION) -current_version $(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
endif
@@ -127,7 +126,6 @@ ifeq ($(PORTNAME), darwin)
shlib_major = lib$(NAME).$(SO_MAJOR_VERSION)$(DLSUFFIX)
else
# loadable module
- DLSUFFIX = .so
LINK.shared = $(COMPILER) -bundle -multiply_defined suppress
endif
BUILD.exports = $(AWK) '/^[^\#]/ {printf "_%s\n",$$1}' $< >$@
diff --git a/src/makefiles/Makefile.darwin b/src/makefiles/Makefile.darwin
index 4fc81c1584..45f253a5b4 100644
--- a/src/makefiles/Makefile.darwin
+++ b/src/makefiles/Makefile.darwin
@@ -10,5 +10,5 @@ else
endif
# Rule for building a shared library from a single .o file
-%.so: %.o
+%$(DLSUFFIX): %.o
$(CC) $(CFLAGS) $< $(LDFLAGS) $(LDFLAGS_SL) -bundle $(BE_DLLLIBS) -o $@
diff --git a/src/template/darwin b/src/template/darwin
index e14d53b601..fd30e19b6a 100644
--- a/src/template/darwin
+++ b/src/template/darwin
@@ -55,3 +55,5 @@ case $host_os in
USE_SYSV_SEMAPHORES=1
;;
esac
+
+DLSUFFIX=".dylib"
--
2.36.1
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.