On Tue, Jul 6, 2021 at 2:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> > I think this change is perfectly appropriate (modulo some small cleanups).
>
> I think there are a couple of issues here.
>
> 1. People who are already using MACOSX_DEPLOYMENT_TARGET to control
> their builds would like to keep on doing so, but the AC_CHECK_FUNCS
> probe doesn't work with that. James' latest patch seems like a
> reasonable fix for that (it's a lot less invasive than where we
> started from). There is a worry about side-effects on other
> platforms, but I don't see an answer to that that's better than
> "throw it on the buildfarm and see if anything breaks".
>
> However ...
>
> 2. We'd really like to use preadv/pwritev where available. I
> maintain that MACOSX_DEPLOYMENT_TARGET is not only not the right
> approach to that, but it's actually counterproductive. It forces
> you to build for the lowest common denominator, ie the oldest macOS
> release you want to support. Even when running on a release that
> has pwritev, your build will never use it.
>
> As far as I can tell, the only way to really deal with #2 is to
> perform a runtime dlsym() probe to see whether pwritev exists, and
> then fall back to our src/port/ implementation if not. This does
> not look particularly hard (especially since the lookup code only
> needs to work on macOS), though I admit I've not tried to code it.
Maybe we just need to do something like this?:
https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg06499.html
>
> What's unclear to me at the moment is whether #1 and #2 interact,
> ie is there still any point in changing configure's probes if
> we put in a runtime check on Darwin? I think that we might want
> to pay no attention to what the available header files say about
> pwritev, as long as we can get the correct 'struct iovec'
> declaration from them.
>
> regards, tom lane
