Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. - Mailing list pgsql-hackers
| From | Sandeep Thakkar |
|---|---|
| Subject | Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. |
| Date | |
| Msg-id | CANFyU94t8xNNSc+gvcJAHutvv7FFWoVEEMDMBYhnry0P1wQ_OQ@mail.gmail.com Whole thread Raw |
| In response to | Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. (James Hilliard <james.hilliard1@gmail.com>) |
| List | pgsql-hackers |
Hi,
I see this issue persist when I compile PG v14 beta1 on macOS Apple M1 using macOS 11.1 SDK. Even though the build didn't fail, the execution of initdb on macOS 10.15 failed with the same error. Here is the snippet of the build log:
--
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -g -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -mmacosx-version-min=10.14 -arch x86_64 -arch arm64 -O2 -I. -I. -I../../../src/include -I/opt/local/Current/include -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk -I/opt/local/20210406/include/libxml2 -I/opt/local/Current/include/libxml2 -I/opt/local/Current/include -I/opt/local/Current/include/openssl/ -c -o backup_manifest.o backup_manifest.c
fd.c:3740:10: warning: 'pwritev' is only available on macOS 11.0 or newer [-Wunguarded-availability-new]
part = pg_pwritev(fd, iov, iovcnt, offset);
^~~~~~~~~~
../../../../src/include/port/pg_iovec.h:49:20: note: expanded from macro 'pg_pwritev'
#define pg_pwritev pwritev
^~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/sys/uio.h:104:9: note: 'pwritev' has been marked as being introduced in macOS 11.0 here, but the deployment target is macOS 10.14.0
ssize_t pwritev(int, const struct iovec *, int, off_t) __DARWIN_NOCANCEL(pwritev) __API_AVAILABLE(macos(11.0), ios(14.0), watchos(7.0), tvos(14.0));
^
fd.c:3740:10: note: enclose 'pwritev' in a __builtin_available check to silence this warning
part = pg_pwritev(fd, iov, iovcnt, offset);
^~~~~~~~~~
../../../../src/include/port/pg_iovec.h:49:20: note: expanded from macro 'pg_pwritev'
#define pg_pwritev pwritev
--
initdb failure:
--
The database cluster will be initialized with locales
COLLATE: C
CTYPE: UTF-8
MESSAGES: C
MONETARY: C
NUMERIC: C
TIME: C
The default database encoding has accordingly been set to "UTF8".
initdb: could not find suitable text search configuration for locale "UTF-8"
The default text search configuration will be set to "simple".
Data page checksums are disabled.
creating directory /tmp/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Asia/Kolkata
creating configuration files ... ok
running bootstrap script ... dyld: lazy symbol binding failed: Symbol not found: _pwritev
Referenced from: /Library/PostgreSQL/14/bin/postgres
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _pwritev
Referenced from: /Library/PostgreSQL/14/bin/postgres
Expected in: /usr/lib/libSystem.B.dylib
child process was terminated by signal 6: Abort trap: 6
initdb: removing data directory "/tmp/data"
--
On Wed, Mar 31, 2021 at 7:49 AM James Hilliard <james.hilliard1@gmail.com> wrote:
On Tue, Mar 30, 2021 at 7:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Thomas Munro <thomas.munro@gmail.com> writes:
> > 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. 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? If so I wonder if other projects are running
> > into this with AC_REPLACE_FUNCS and what they're doing.
>
> Yeah, we've seen this happen at least a couple of times, though
> it was only during this past cycle that we (I anyway) entirely
> understood what was happening.
>
> The patches we committed in January (4823621db, 9d23c15a0, 50bebc1ae)
> to improve our PG_SYSROOT selection heuristics should theoretically
> improve the situation ... though I admit I won't have a lot of
> confidence in them till we've been through a couple more rounds of
> asynchronous-XCode-and-macOS releases. Still, I feel that we
> ought to leave that code alone until we see how it does.
I mean, we know that it will still break under a number of common
circumstances so I think we should be fixing the root cause(improper
detection of target deployment API availability in probes) in some
way as this will probably continue to be an issue otherwise, we already
know that improving PG_SYSROOT selection can not fix the root issue
but rather tries to workaround it in a way that is pretty much guaranteed
to be brittle.
Is there any approach to fixing the root cause of this issue that you think
would be acceptable?
>
> regards, tom lane
Sandeep Thakkar
pgsql-hackers by date: