From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Sergey Shinderuk <s.shinderuk@postgrespro.ru>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_preadv() and pg_pwritev()
In-reply-to: <1297389.1610562046@sss.pgh.pa.us>
References: 
 <CA+hUKGJA+u-220VONeoREBXJ9P3S94Y7J+kqCnTYmahvZJwM=g@mail.gmail.com>
 <341497.1608420857@sss.pgh.pa.us>
 <CA+hUKG+7UHOH2VGRwvJZ=vXUH9pRA-Tp3gP9EHgtjwzjyfOpWg@mail.gmail.com>
 <20201220224040.evr5pduibvm6dze5@alap3.anarazel.de>
 <CA+hUKG+TCoareSYcAu05yaMh9eUck6Hd8FQZt5VEvotNs3YOMQ@mail.gmail.com>
 <CA+hUKGJ8Ww_fjzUzthdxUF6W3JQ3r=a1hWX7Fcfq9uEndZ_+GQ@mail.gmail.com>
 <CA+hUKGL9XFxM0ZO8ZADYJepSmjywknhnDkKSEttfmn2j9fg0BQ@mail.gmail.com>
 <ed3b8e5d-0da8-6ebd-fd1c-e0ac80a4b204@postgrespro.ru>
 <CA+hUKG+L573j4=XWv6S+r-687Yxn0FyXhtObH9_P-Nu_atL2pQ@mail.gmail.com>
 <448b3cb5-0ba0-6dc5-63c7-789e4eebc40b@postgrespro.ru>
 <1283127.1610554395@sss.pgh.pa.us> <1286060.1610558607@sss.pgh.pa.us>
 <1297389.1610562046@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 13 Jan 2021 13:20:46 -0500"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1341554.1610580049.0@sss.pgh.pa.us>
Date: Wed, 13 Jan 2021 18:22:02 -0500
Message-ID: <1341608.1610580122@sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1341554.1610580049.1@sss.pgh.pa.us>

I wrote:
> So I'm a little confused as to why this test is failing to fail
> with (I assume) newer Xcode.  Can we see the relevant part of
> config.log on your machine?

After further digging I believe I understand what's happening,
and it's a bit surprising we've not been bit by it before.
If the compiler believes (thanks to __API_AVAILABLE macros in
Apple's system headers) that a given library symbol might not
exist in the lowest macOS version it is compiling for, it will
still emit a normal call to that function ... but it also emits

       .weak_reference _preadv

marking the call as a weak reference.  If the linker then fails
to link that call, it doesn't throw an error, it just replaces
the call instruction with a NOP :-(.  This is why configure's
test appears to succeed, since it only checks whether you can
link not whether the call would work at runtime.  Apple's
assumption evidently is that you'll guard the call with a run-time
check to see if the function exists before you use it, and you
don't want your link to fail if it doesn't.

The solution to this, according to "man ld", is

     -no_weak_imports
                 Error if any symbols are weak imports (i.e. allowed to be
                 unresolved (NULL) at runtime). Useful for config based
                 projects that assume they are built and run on the same OS
                 version.

I don't particularly care that Apple is looking down their nose
at people who don't want to make their builds run on multiple OS
versions, so I think we should just use this and call it good.

Attached is an untested quick hack to make that happen --- Sergey,
can you verify that this fixes configure's results on your setup?

(This is not quite committable as-is, it needs something to avoid
adding -Wl,-no_weak_imports on ancient macOS versions.  But it
will do to see if the fix works on modern versions.)

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="forbid-weak-linking-on-macos.patch";
	charset="us-ascii"
Content-ID: <1341554.1610580049.2@sss.pgh.pa.us>
Content-Description: forbid-weak-linking-on-macos.patch

diff --git a/src/template/darwin b/src/template/darwin
index 32414d21a9..22d04e7ba7 100644
--- a/src/template/darwin
+++ b/src/template/darwin
@@ -17,6 +17,9 @@ if test x"$PG_SYSROOT" != x"" ; then
   fi
 fi
 
+# Disable weak linking, else configure's checks will misbehave
+LDFLAGS="-Wl,-no_weak_imports $LDFLAGS"
+
 # Extra CFLAGS for code that will go into a shared library
 CFLAGS_SL=""
 

------- =_aaaaaaaaaa0--