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

From: James Hilliard <james(dot)hilliard1(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: [PATCH 1/1] Fix detection of pwritev support for OSX.
Date: 2021-01-19 16:49:58
Message-ID: CADvTj4o6LEGRJSRR4H8Rmn8r_vv4ZE_mS0MS5Z60NwDZRwdZHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 19, 2021 at 8:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> > On Tue, Jan 19, 2021 at 8:27 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> We already dealt with that by not selecting an SDK newer than the
> >> underlying OS (see 4823621db).
>
> > Tried that, doesn't work, not even sure how it could possibly fix this
> > issue at all,
>
> It worked for me and for Sergey, so we need to figure out what's different
> about your setup. What do you get from "xcrun --show-sdk-path" and
> "xcrun --sdk macosx --show-sdk-path"? What have you got under
> /Library/Developer/CommandLineTools/SDKs ?
$ xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
$ xcrun --sdk macosx --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk
$ ls -laht /Library/Developer/CommandLineTools/SDKs
total 0
drwxr-xr-x 5 root wheel 160B Jan 14 2020 .
drwxr-xr-x 8 root wheel 256B Jan 14 2020 MacOSX10.15.sdk
drwxr-xr-x 7 root wheel 224B Jan 14 2020 MacOSX10.14.sdk
lrwxr-xr-x 1 root wheel 15B Jan 14 2020 MacOSX.sdk -> MacOSX10.15.sdk
>
> > this can not be fixed properly by selecting a specific SDK version
> > alone, it's the symbols valid for a specific target deployment version
> > that matters here.
>
> I don't think I believe that argument. As a counterexample, supposing
> that somebody were intentionally cross-compiling on an older OSX platform
> but using a newer SDK, shouldn't they get an executable suited to the
> SDK's target version?
Yep, that's exactly what this should fix:

MACOSX_DEPLOYMENT_TARGET=11.0 ./configure
checking for pwritev... yes

Which fails at runtime on 10.15:
dyld: lazy symbol binding failed: Symbol not found: _pwritev
Referenced from: /usr/local/pgsql/bin/postgres (which was built for
Mac OS X 11.0)
Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _pwritev
Referenced from: /usr/local/pgsql/bin/postgres (which was built for
Mac OS X 11.0)
Expected in: /usr/lib/libSystem.B.dylib

child process was terminated by signal 6: Abort trap: 6

MACOSX_DEPLOYMENT_TARGET=10.15 ./configure
checking for pwritev... no

Noticed a couple small issues, I'll send a v2.
>
> (I realize that Apple thinks we ought to handle that through run-time
> not compile-time adaptation, but I have no interest in going there.)
>
> regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-01-19 16:53:02 Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault
Previous Message Julien Rouhaud 2021-01-19 16:43:25 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?