Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.

On Tue, Mar 30, 2021 at 6:43 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Tue, Mar 30, 2021 at 7:39 PM James Hilliard
> <james(dot)hilliard1(at)gmail(dot)com> wrote:
> > On Mon, Mar 29, 2021 at 11:58 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > We haven't claimed in the past to support MACOSX_DEPLOYMENT_TARGET,
> > > and I'm not sure we should start now. How many people actually care
> > > about that?
> >
> > Seems kinda important for anyone who wants to build postgres
> > compatible with targets older than the host system.
>
> Personally I'm mostly concerned about making it easy for new
> contributors to get a working dev system going on a super common
> platform without dealing with hard-to-diagnose errors, than people who
> actually want a different target as a deliberate choice.

Yeah, that's where I was running into this. Currently we build for the max
deployment target available in the SDK, regardless of if that is the deployment
target actually set, the compiler by default automatically sets the deployment
target to the build host but if the SDK supports newer deployment targets
that's where things break down.

> Do I
> understand correctly that there a period of time each year when major
> upgrades come out of sync and lots of people finish up running a
> toolchain and OS with this problem for a while due to the default
> target not matching?

Well you can hit this if you try and build against a toolchain that supports
targets newer than the host pretty easily, although I think postgres
tries to use the cli tools SDK by default which appears somewhat less
prone to this issue(although I don't think this behavior is guaranteed).

> If so I wonder if other projects are running
> into this with AC_REPLACE_FUNCS and what they're doing.

Well I did come up with another approach, which uses AC_LANG_PROGRAM
instead of AC_CHECK_DECLS that might be better
https://lists.gnu.org/archive/html/autoconf-patches/2021-02/msg00007.html

However I didn't submit that version here since it uses a custom probe via
AC_LANG_PROGRAM instead of a standard probe like AC_CHECK_DECLS
which Tom Lane said would be a maintenance issue, at least with this
AC_CHECK_DECLS method we can avoid using any non-standard probes:
https://postgr.es/m/915981.1611254324%40sss.pgh.pa.us

>
> I suppose an alternative strategy would be to try to detect the
> mismatch and spit out a friendlier warning, if we decide we're not
> going to support such builds.