On Thu, Nov 19, 2020 at 9:02 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> > On Thu, Nov 19, 2020 at 7:48 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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"
>
> True. Also, while actual documentation on -isysroot seems to be damn
> near nonexistent, all the example usages I can find on the net appear
> to put it into both compile and link steps. So maybe we're just doing
> it wrong and happened to get away with that this long.
Yeah, pretty sure that's what happened from what I'm seeing.
>
> > 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.
>
> Yeah, the one saving grace here is that, unlike the last time, we're not
> hard up against a release deadline. If we push this now we can hope to
> get a fair amount of testing from PG developers before we have to ship
> it.
>
> regards, tom lane