macOS 15.4 versus strchrnul()
Last night I updated the machine that hosts sifaka and indri
to spankin' new macOS Sequoia 15.4, and that promptly broke
the build on both animals:
snprintf.c:350:1: error: static declaration of 'strchrnul' follows non-static declaration
350 | strchrnul(const char *s, int c)
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX15.4.sdk/usr/include/_string.h:198:9: note: previous declaration is here
198 | strchrnul(const char *__s, int __c);
| ^
snprintf.c:414:27: error: 'strchrnul' is only available on macOS 15.4 or newer [-Werror,-Wunguarded-availability-new]
414 | const char *next_pct = strchrnul(format + 1, '%');
| ^~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX15.4.sdk/usr/include/_string.h:198:9: note: 'strchrnul' has been marked as being introduced in macOS 15.4 here, but the deployment target is macOS 15.0.0
198 | strchrnul(const char *__s, int __c);
| ^
snprintf.c:414:27: note: enclose 'strchrnul' in a __builtin_available check to silence this warning
That is, the function exists now in macOS' libc, and so configure's
does-it-link test for HAVE_STRCHRNUL finds it, but <string.h>
will not let you use it unless you monkey around with
export MACOSX_DEPLOYMENT_TARGET=15.4
or similar. I don't think we want to require people to do that,
so we need to fix things so that the code works with or without
a deployment target that satisfies <string.h>. This is pretty
reminiscent of a problem that we faced a couple years ago with
preadv and pwritev, and solved in commit f014b1b9b by depending
on AC_CHECK_DECLS instead of AC_CHECK_FUNCS. I made a patch
(attached) to solve this similarly. Interestingly, this actually
makes the one usage in snprintf.c simpler, since we no longer
need to special-case the situation where GNU <string.h> doesn't
agree with the does-it-link test.
However ... testing this here shows that it fixes the autoconf
build as desired, with or without MACOSX_DEPLOYMENT_TARGET.
But the meson version *does not work*: it will set
HAVE_DECL_STRCHRNUL to 1 with or without MACOSX_DEPLOYMENT_TARGET,
and in the "without" case the build then blows up.
I speculate that the meson test for preadv/pwritev has never worked
for macOS either, and we haven't noticed because nobody has tried to
build with meson on a machine with low enough default deployment
target to not have preadv/pwritev.
I do not know nearly enough about meson to fix that test;
can anyone help?
regards, tom lane
Attachments:
wip-fix-configure-strchrnul-check.patchtext/x-diff; charset=us-ascii; name=wip-fix-configure-strchrnul-check.patchDownload+28-20
On 01.04.25 17:57, Tom Lane wrote:
That is, the function exists now in macOS' libc, and so configure's
does-it-link test for HAVE_STRCHRNUL finds it, but <string.h>
will not let you use it unless you monkey around withexport MACOSX_DEPLOYMENT_TARGET=15.4
or similar. I don't think we want to require people to do that,
so we need to fix things so that the code works with or without
a deployment target that satisfies <string.h>. This is pretty
reminiscent of a problem that we faced a couple years ago with
preadv and pwritev, and solved in commit f014b1b9b by depending
on AC_CHECK_DECLS instead of AC_CHECK_FUNCS. I made a patch
(attached) to solve this similarly. Interestingly, this actually
makes the one usage in snprintf.c simpler, since we no longer
need to special-case the situation where GNU <string.h> doesn't
agree with the does-it-link test.
Agreed, this matches my research.
However ... testing this here shows that it fixes the autoconf
build as desired, with or without MACOSX_DEPLOYMENT_TARGET.
But the meson version *does not work*: it will set
HAVE_DECL_STRCHRNUL to 1 with or without MACOSX_DEPLOYMENT_TARGET,
and in the "without" case the build then blows up.I speculate that the meson test for preadv/pwritev has never worked
for macOS either, and we haven't noticed because nobody has tried to
build with meson on a machine with low enough default deployment
target to not have preadv/pwritev.
Agreed. Attached is a patch that implements the test more along the
lines of how Autoconf does it. This gives correct results for me for
strchrnul() in various configurations.
Btw., I see on the buildfarm that strchrnul() is also available on
FreeBSD, DragonFly BSD, NetBSD, and musl (Alpine Linux). So perhaps
some of the comments ought to be rewritten away from that it's a
glibc-specific extension.
Attachments:
0001-WIP-Fix-AC_CHECK_DECLS-equivalent-in-meson.patchtext/plain; charset=UTF-8; name=0001-WIP-Fix-AC_CHECK_DECLS-equivalent-in-meson.patchDownload+17-3
Peter Eisentraut <peter@eisentraut.org> writes:
On 01.04.25 17:57, Tom Lane wrote:
I speculate that the meson test for preadv/pwritev has never worked
for macOS either, and we haven't noticed because nobody has tried to
build with meson on a machine with low enough default deployment
target to not have preadv/pwritev.
Agreed. Attached is a patch that implements the test more along the
lines of how Autoconf does it. This gives correct results for me for
strchrnul() in various configurations.
Cool. Let me try it here, and I'll push if no problems arise.
Btw., I see on the buildfarm that strchrnul() is also available on
FreeBSD, DragonFly BSD, NetBSD, and musl (Alpine Linux). So perhaps
some of the comments ought to be rewritten away from that it's a
glibc-specific extension.
OK, will do something about that --- maybe like "originally glibc
specific, but later adopted by other platforms"?
regards, tom lane