Build macOS shared modules as dylib rather than bundle - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Build macOS shared modules as dylib rather than bundle
Date
Msg-id aef85d99-5b72-40fc-a334-724e5337b11f@eisentraut.org
Whole thread Raw
Responses Re: Build macOS shared modules as dylib rather than bundle
List pgsql-hackers
I'm splitting this out from [0] so that it can be tracked and referenced 
separately.

[0]: 
https://www.postgresql.org/message-id/170e7e57-fe43-4e7e-8566-a96fcdf23075%40eisentraut.org

Historically, bundles (ld -bundle) were the only file type that could
be dynamically loaded at run time on macOS (OS X at the time).  These
were distinct from dynamic libraries (ld -dynamiclib (although the man
page says -dylib, but that apparently doesn't work)) that you use at
build time (-lfoo).  Therefore, that platform had a strict distinction
between shared libraries and shared modules, unlike other platforms.

Over time, macOS gained the ability to dlopen dynamic libraries as
well, so this distinction is obsolete.  Also, it appears that the
bundle file type is obsolescent on other Apple platforms.  So, to
simplify this, change our shared library makefiles to build the
dynamic library file type for both uses.  (There are still some
distinctions between the two in the build system, such as where they
are installed and how the output files are named, but they are now
internally the same file type.)  Meson also has the same change
pending in its master branch, so this will eventually become
consistent.

But this change triggers a new variant of this issue:

https://www.postgresql.org/message-id/E1o4HOv-001Oyi-5n@gemulon.postgresql.org

With the changed linker options, the symbol search order appears to
be different, and so hash_search() gets found in the OS library first.

(Historical research reveals that this name clash is not accidental. 
dynahash.c was explicitly modeled after routines that existed in some 
BSD OS, and continue to exist in macOS, but they don't have compatible 
signatures.)

To avoid that, I suggest to use some preprocessor defines to rename the 
symbols known to clash, in a way that we can continue to use the 
existing API names.


I suggest that we consider the dynahash change for PG18.  The Meson 
change will eventually come our way, and then everything on macOS will 
start crashing.  So the earlier we fix this the better.  Also, we can't 
backpatch this because of the ABI change, so once PG18 ships the window 
is over.

For the -bundle -> -dynamiclib change, I don't have any particular 
urgency right now.


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Consistently use macro HeapTupleIsValid to check the validity of tuples in tablecmds.c
Next
From: Tomas Vondra
Date:
Subject: Re: Draft for basic NUMA observability