Horton

Thread

Commits

  1. Fix detection and handling of strchrnul() for macOS 15.4.

  2. Probe for preadv/pwritev in a more macOS-friendly way.

  1. macOS 15.4 versus strchrnul()

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-04-01T15:57:18Z

    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

  2. Re: macOS 15.4 versus strchrnul()

    Peter Eisentraut <peter@eisentraut.org> — 2025-04-01T17:07:02Z

    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 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.

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.

  3. Re: macOS 15.4 versus strchrnul()

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-04-01T19:25:59Z

    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