Skip to content

build: bring the _Generic-from-glibc-2.43 patch in line with upstream#6242

Merged
dscho merged 2 commits into
git-for-windows:mainfrom
dscho:tolerate-glibc-generic-with-clang
Jun 11, 2026
Merged

build: bring the _Generic-from-glibc-2.43 patch in line with upstream#6242
dscho merged 2 commits into
git-for-windows:mainfrom
dscho:tolerate-glibc-generic-with-clang

Conversation

@dscho

@dscho dscho commented May 12, 2026

Copy link
Copy Markdown
Member

Upstream has landed Patrick Steinhardt's patch build: tolerate use of _Generic from glibc 2.43 with Clang in a form that differs from what we currently carry as 74c3ea9 (a cherry-pick of Patrick's v1). The upstream variant on next (commit 0a6d290) carries the trailer [jc: replaced Makefile side with Shardul's approach] and is signed off by Junio.

Concretely, instead of dropping -std=gnu99 for Clang in config.mak.dev, the upstream variant keeps -std=gnu99 and adds -Wno-c11-extensions for Clang in a dedicated top-level block, mirroring what Patrick already did on the Meson side. Keeping -std=gnu99 is desirable because it still lets us catch accidental use of newer-than-C99 features in Git's own code.

This PR is the amend! commit that brings our downstream pick in line with that upstream landing. Autosquashing onto the parent of 74c3ea9 produces a single commit whose tree state is identical to 0a6d290 (modulo our USE_MIMALLOC carry inside the gcc6/clang7 block on the Makefile side). The intended merge strategy is autosquash-then-force-push to main, not a regular merge commit, so the history mirrors what landed upstream.

Junio's confirmation that he is fast-tracking the topic to next and master is at https://lore.kernel.org/git/xmqqecjischc.fsf@gitster.g.

build: tolerate use of _Generic from glibc 2.43 with Clang

When building with `make DEVELOPER=1` we explicitly pass "-std=gnu99" to
the compiler so that we don't start leaning on features exposed by more
recent versions of the C standard. Unfortunately though, glibc 2.43
started to use type-generic expressions. This works alright with GCC,
but when compiling with Clang this leads to errors:

  $ make DEVELOPER=1 CC=clang
  CC daemon.o
  In file included from daemon.c:3:
  ./git-compat-util.h:344:11: error: '_Generic' is a C11 extension [-Werror,-Wc11-extensions]
    344 |         return !!strchr(path, '/');
        |                  ^
  /usr/include/string.h:265:3: note: expanded from macro 'strchr'
    265 |   __glibc_const_generic (S, const char *, strchr (S, C))
        |   ^
  /usr/include/x86_64-linux-gnu/sys/cdefs.h:838:3: note: expanded from macro '__glibc_const_generic'
    838 |   _Generic (0 ? (PTR) : (void *) 1,                     \
        |   ^

In theory, the `__glibc_const_generic` macro does have feature gating:

  #if !defined __cplusplus \
      && (__GNUC_PREREQ (4, 9) \
          || __glibc_has_extension (c_generic_selections) \
          || (!defined __GNUC__ && defined __STDC_VERSION__ \
              && __STDC_VERSION__ >= 201112L))
  # define __HAVE_GENERIC_SELECTION 1
  #else
  # define __HAVE_GENERIC_SELECTION 0
  #endif

But this feature gating isn't effective because `_has_extension()` will
always evaluate to true as C generics _are_ available as a language
extension to GNU C99 when using Clang. This would have been different if
`_has_feature()` was used instead, in which case it would have properly
evaluated to `false`.

GCC has a workaround to squelch this warning from standard system
headers, but because clang fails due to [-Werror,-Wc11-extensions],
as it lacks the corresponding workaround.

For both meson and Makefile, pass -Wno-c11-extensions when we are
building with clang.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Helped-by: Shardul Natu <snatu@google.com>
[jc: replaced Makefile side with Shardul's approach]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Assisted-by: Opus 4.7
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho self-assigned this May 12, 2026
@dscho

dscho commented May 12, 2026

Copy link
Copy Markdown
Member Author

I bet this conflicts with #6231, and I'd actually like the latter to land first.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho

dscho commented Jun 10, 2026

Copy link
Copy Markdown
Member Author

Seems that an unrelated update broke the win+VS build (so far, the only difference I can detect is that the CMake configuration targets VS 18, and then MSBuild fails to find git.sln, while it worked two days ago targeting VS 17).

@dscho dscho added this to the Next release milestone Jun 11, 2026
@dscho dscho merged commit cda0b14 into git-for-windows:main Jun 11, 2026
232 of 243 checks passed
@dscho dscho deleted the tolerate-glibc-generic-with-clang branch June 11, 2026 07:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants