public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Build macOS shared modules as dylib rather than bundle
Date: Wed, 09 Apr 2025 11:11:14 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

Peter Eisentraut <[email protected]> writes:
> ... But this change triggers a new variant of this issue:
> https://www.postgresql.org/message-id/[email protected]
> With the changed linker options, the symbol search order appears to
> be different, and so hash_search() gets found in the OS library first.

> 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 don't love that solution.  If we simply put up with this name
resolution order, we leave ourselves open to being blindsided by
any future libc addition that Apple chooses to make.  The recent
strchrnul() kerfuffle is still causing me pain every day, so
maybe this is more front-of-mind than it would be at another time.
But I think it is worth our time to try to find a way to get back
the other resolution order.

> 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.

Arguably, changing library name resolution order is an ABI break
in itself.  If we can't fix that, I think we will have to mandate
that this change happens only at a major-release boundary.  Which
is going to be no fun for anybody, if meson is going to force it
on us across-the-board at some random time.  We should perhaps
push back on the idea that they get to decide when and how that
changes.

			regards, tom lane

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Build macOS shared modules as dylib rather than bundle
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox