On Tue, Jul 6, 2021 at 2:34 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Peter Eisentraut <peter.eisentr...@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
