On Thu, Nov 19, 2020 at 7:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > However ... it then occurred to me to blow away my ccache and accache,
> > and after rebuilding from scratch, everything's fine. So, are you
> > using ccache?
>
> Oh, scratch that, I fat-fingered the experiment somehow. The issue
> is still there. Still, I'm hesitant to apply the fix you suggest,
> because of the law of unintended consequences. In particular, I'm
> afraid that using -isysroot in the link step might result in executables
> that are bound to that sysroot and will not work if it's not there
> --- thus causing a problem for packagers trying to distribute PG
> to non-developers.
Since apple doesn't actually put real dylib's in the SDK path I think
we're fine:
$ find /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk
-name "*.dylib"
$
Instead they use .tbd or text-based stub files there which appear to provide
enough info for the linker to determine that the undefined symbols are
weak linked. And since the linker doesn't actually link against the
.tbd file paths
in the way it would a dylib I don't think the SDK path could get used
accidentally.
>
> We had a great deal of trouble in the initial experiments with
> -isysroot, cf
>
> https://www.postgresql.org/message-id/flat/20840.1537850987%40sss.pgh.pa.us
>
> so I'm not that eager to mess with it. I'm inclined to think that
> this is more a case of "Apple broke ABI and they ought to fix that".
This seems to be a longstanding issue, I expect they don't care much about
autotools compared with their normal Xcode project build system. So probably
better to just give this a try and see how it goes as it's likely to
keep popping up
otherwise.
>
> regards, tom lane
