pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedUnify DLSUFFIX on Darwin
6+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2022-07-06 b55f62abb2 Unify DLSUFFIX on Darwin
* Unify DLSUFFIX on Darwin
@ 2022-06-22 11:12 Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-22 13:45 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 6+ messages in thread
From: Peter Eisentraut @ 2022-06-22 11:12 UTC (permalink / raw)
To: pgsql-hackers
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.patch (text/plain, 4.0K) download
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
* Re: Unify DLSUFFIX on Darwin
2022-06-22 11:12 Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
@ 2022-06-22 13:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-06-24 11:26 ` Re: Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2022-06-22 13:45 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unify DLSUFFIX on Darwin
2022-06-22 11:12 Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-22 13:45 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-06-24 11:26 ` Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-24 14:13 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 6+ messages in thread
From: Peter Eisentraut @ 2022-06-24 11:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
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.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unify DLSUFFIX on Darwin
2022-06-22 11:12 Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-22 13:45 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
2022-06-24 11:26 ` Re: Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
@ 2022-06-24 14:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-06-28 15:12 ` Re: Unify DLSUFFIX on Darwin Andrew Dunstan <andrew@dunslane.net>
2022-07-06 06:08 ` Re: Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
0 siblings, 2 replies; 6+ messages in thread
From: Tom Lane @ 2022-06-24 14:13 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unify DLSUFFIX on Darwin
2022-06-22 11:12 Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-22 13:45 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
2022-06-24 11:26 ` Re: Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-24 14:13 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-06-28 15:12 ` Andrew Dunstan <andrew@dunslane.net>
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Dunstan @ 2022-06-28 15:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@enterprisedb.com>; +Cc: pgsql-hackers
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unify DLSUFFIX on Darwin
2022-06-22 11:12 Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-22 13:45 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
2022-06-24 11:26 ` Re: Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-24 14:13 ` Re: Unify DLSUFFIX on Darwin Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-07-06 06:08 ` Peter Eisentraut <peter.eisentraut@enterprisedb.com>
1 sibling, 0 replies; 6+ messages in thread
From: Peter Eisentraut @ 2022-07-06 06:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
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.
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2022-07-06 06:08 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-06-22 11:12 Unify DLSUFFIX on Darwin Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-22 13:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-06-24 11:26 ` Peter Eisentraut <peter.eisentraut@enterprisedb.com>
2022-06-24 14:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-06-28 15:12 ` Andrew Dunstan <andrew@dunslane.net>
2022-07-06 06:08 ` Peter Eisentraut <peter.eisentraut@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox