Page MenuHome GnuPG

_DARWIN_C_SOURCE kind of "must" be 1, not "900000L"
Closed, ResolvedPublic

Description

In configure.ac, _DARWIN_C_SOURCE is defined to 900000L.

297     *-apple-darwin*)
298         AC_DEFINE(_DARWIN_C_SOURCE, 900000L,
299                   Expose all libc features (__DARWIN_C_FULL).)

This was done as part of commit 654024081cfa103c87bb163b117ea3568171d408.

Later in configure.ac, -Werror is activated, to detect unknown attributes.

1077 # Following attribute tests depend on warnings to cause compile to fail,
1078 # so set -Werror temporarily.
1079 _gcc_cflags_save=$CFLAGS
1080 CFLAGS="$CFLAGS -Werror"

This is used to detect, for example, support for aligned.

The new cipher-gcm-intel-pclmul implementation does not work unless NEED_16BYTE_ALIGNED_CONTEXT is set (otherwise, there is a gpf accessing the context's key); this is, in turn, only set if HAVE_GCC_ATTRIBUTE_ALIGNED has been defined by the configure scripts. (BTW, that this is as brittle as it is--crashing at runtime if you are using a compiler that doesn't support this particular attribute--is maybe worth looking at: if aligned isn't supported, this new gcm implementation must be avoided, as the alignment is no longer merely a performance improvement.)

However, this test fails on macOS due to the following:

configure:16651: checking whether the GCC style aligned attribute is supported
configure:16662: clang -mmacosx-version-min=10.14 -isysroot /Applications/Xcode_11.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -resource-dir /Applications/Xcode_11.3.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0 -B./ -fno-strict-return -arch x86_64 -target x86_64-apple-darwin18.5.0 -c -gfull -Os -fno-omit-frame-pointer -DPIC -fPIC -fno-ident -Werror  conftest.c >&5 
conftest.c:40:9: error: '_DARWIN_C_SOURCE' macro redefined [-Werror,-Wmacro-redefined]
#define _DARWIN_C_SOURCE 900000L 
        ^       
conftest.c:23:9: note: previous definition is here 
#define _DARWIN_C_SOURCE 1
        ^       
1 error generated.
configure:16662: $? = 1

The issue is that configure already sets _DARWIN_C_SOURCE.

5638   printf "%s\n" "#define _DARWIN_C_SOURCE 1" >>confdefs.h

This is in specific.m4, and it is using AC_DEFINE's default of 1.

502   AC_DEFINE([_DARWIN_C_SOURCE])

This define is new, as of autoconf 2.71, and was not done by 2.69.

https://sources.debian.org/src/autoconf/2.71-1/lib/autoconf/specific.m4/#L502

FWIW, I've never heard of _DARWIN_C_SOURCE being non-1. If you grep Apple's SDK, it only ever checks whether this variable is defined.

Searching for 900000L, I believe there was some confusion with respect to _DARWIN_C_LEVEL: if you set _DARWIN_C_SOURCE, it sets __DARWIN_C_LEVEL to __DARWIN_C_FULL, which is 900000L; however, this is different from setting _DARWIN_C_SOURCE, which should only be set to 1.

/*
 * Set a single macro which will always be defined and can be used to determine
 * the appropriate namespace.  For POSIX, these values will correspond to
 * _POSIX_C_SOURCE value.  Currently there are two additional levels corresponding
 * to ANSI (_ANSI_SOURCE) and Darwin extensions (_DARWIN_C_SOURCE)
 */
#define __DARWIN_C_ANSI         010000L
#define __DARWIN_C_FULL         900000L

#if   defined(_ANSI_SOURCE)
#define __DARWIN_C_LEVEL        __DARWIN_C_ANSI
#elif defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE) && !defined(_NONSTD_SOURCE)
#define __DARWIN_C_LEVEL        _POSIX_C_SOURCE
#else
#define __DARWIN_C_LEVEL        __DARWIN_C_FULL
#endif

If libgcrypt sets this variable to 1, everything works correctly again.

diff --git a/configure.ac b/configure.ac
index a874c411..37947ecb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -295,7 +295,7 @@ case "${host}" in
     m68k-atari-mint)
         ;;
     *-apple-darwin*)
-        AC_DEFINE(_DARWIN_C_SOURCE, 900000L,
+        AC_DEFINE(_DARWIN_C_SOURCE, 1,
                   Expose all libc features (__DARWIN_C_FULL).)
         AC_DEFINE(USE_POSIX_SPAWN_FOR_TESTS, 1,
                   [defined if we use posix_spawn in test program])

In the meantime, developers must pass -Wno-macro-redefined through CPPFLAGS as a workaround.

Event Timeline

Note: I believe this issue might affect multiple other GnuPG projects.

gniibe added a subscriber: gniibe.

Thank you for your report.

It was pushed to handle the task T2910: gpgme 1.8 build failure: strdup undeclared on MacOSX Sierra.

I'll fix all packages.

Done for all (libgcrypt (master, 1.9, and 1.8), libassuan, ntbtls, libksba, gpgme, gnupg (2.2 and 2.3).

gniibe changed the task status from Open to Testing.May 27 2021, 6:41 AM
gniibe triaged this task as Normal priority.
gniibe added a project: Testing.
werner moved this task from For 1.8 to For 1.9 on the libgcrypt board.
werner moved this task from For 1.9 to Backlog on the libgcrypt board.
gniibe removed a project: Testing.