config.mak.dev: suppress C11 extension warning for Clang on Linux
PATCH 1/1 config.mak.dev: suppress C11 extension warning for Clang on Linux
From: Shnatu <[email protected]>
When building Git with Clang on Linux with DEVELOPER=1, the build fails because Clang treats C11 features used in glibc headers as extensions and raises errors due to -std=gnu99, -pedantic, and -Werror.
Specifically, glibc's string.h uses _Generic (a C11 feature) in macros like strchr. When these macros are expanded in Git's C files, Clang warns about them being C11 extensions.
GCC does not exhibit this behavior because it suppresses pedantic warnings for macros defined in system headers.
To fix this, add -Wno-c11-extensions to DEVELOPER_CFLAGS when using Clang, but restrict it to Linux (uname_S == Linux). This suppresses the warning for glibc headers while keeping the build strict on other platforms (like macOS) to catch accidental C11 usage in Git's own code.
---
config.mak.dev: suppress C11 extension warning for Clang on Linux
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2291%2Fkiranani%2Fnext-2-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2291/kiranani/next-2-v1
Pull-Request: https://github.com/git/git/pull/2291
config.mak.dev | 3 +++ 1 file changed, 3 insertions(+)
config.mak.dev +3 -0
@@ -87,6 +87,9 @@ endif # The bug was fixed in Apple clang 12. # ifneq ($(filter clang1,$(COMPILER_FEATURES)),) # if we are using clang +ifeq ($(uname_S),Linux) +DEVELOPER_CFLAGS += -Wno-c11-extensions +endif ifeq ($(uname_S),Darwin) # if we are on darwin ifeq ($(filter clang12,$(COMPILER_FEATURES)),) # if version < 12 DEVELOPER_CFLAGS += -Wno-missing-braces
base-commit: 4f69b47b940100b02630f745a52f9d9850f122b2
Signature · 1 line
gitgitgadget
Quoted 6 lines · Shardul Natu via GitGitGadget
From: Shnatu <[email protected]>
When building Git with Clang on Linux with DEVELOPER=1, the build fails because Clang treats C11 features used in glibc headers as extensions and raises errors due to -std=gnu99, -pedantic, and -Werror.
Hi Shnatu!
This is already being discussed at:
https://lore.kernel.org/git/20260505-b4-pks-ci-tolerate-glibc-generic-v1-1-5786386fe512@pks.im/T/#u
You might want to check out that thread.
Hope this helps,
--
Pablo
Quoted 43 lines
Specifically, glibc's
string.huses_Generic(a C11 feature) in macros like strchr. When these macros are expanded in Git's C files, Clang warns about them being C11 extensions.GCC does not exhibit this behavior because it suppresses pedantic warnings for macros defined in system headers.
To fix this, add -Wno-c11-extensions to
DEVELOPER_CFLAGSwhen using Clang, but restrict it to Linux (uname_S== Linux). This suppresses the warning for glibc headers while keeping the build strict on other platforms (like macOS) to catch accidental C11 usage in Git's own code.Signed-off-by Shnatu <[email protected]>---
config.mak.dev: suppress C11 extension warning for Clang on LinuxPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2291%2Fkiranani%2Fnext-2-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2291/kiranani/next-2-v1
Pull-Request: https://github.com/git/git/pull/2291config.mak.dev | 3 +++ 1 file changed, 3 insertions(+)config.mak.dev +3
-0@@ -87,6 +87,9 @@ endif # The bug was fixed in Apple clang 12. # ifneq ($(filter clang1,$(COMPILER_FEATURES)),) # if we are using clang +ifeq ($(uname_S),Linux) +DEVELOPER_CFLAGS += -Wno-c11-extensions +endif ifeq ($(uname_S),Darwin) # if we are on darwin ifeq ($(filter clang12,$(COMPILER_FEATURES)),) # if version < 12 DEVELOPER_CFLAGS += -Wno-missing-bracesbase-commit:
4f69b47b940100b02630f745a52f9d9850f122b2--
gitgitgadget
Quoted 9 lines · Pablo
Quoted 6 lines · Shardul Natu via GitGitGadget
From: Shnatu <[email protected]>
When building Git with Clang on Linux with DEVELOPER=1, the build fails because Clang treats C11 features used in glibc headers as extensions and raises errors due to -std=gnu99, -pedantic, and -Werror.
Quoted 7 lines
Hi Shnatu!
This is already being discussed at:
https://lore.kernel.org/git/20260505-b4-pks-ci-tolerate-glibc-generic-v1-1-5786386fe512@pks.im/T/#uYou might want to check out that thread.
Hope this helps,
Yes, they aim to solve the same issue, but the approach taken by this patch to use -Wno-c11-extensions on clang may be with less damage than the other approach that drops -std=gnu99 from Makefile.
The other approach uses the equivalent of this patch on the meson side, so it may be doubly so that we should use -Wno-c11-extensions on both build systems, no?
Quoted 42 lines
Quoted 42 lines
Specifically, glibc's
string.huses_Generic(a C11 feature) in macros like strchr. When these macros are expanded in Git's C files, Clang warns about them being C11 extensions.GCC does not exhibit this behavior because it suppresses pedantic warnings for macros defined in system headers.
To fix this, add -Wno-c11-extensions to
DEVELOPER_CFLAGSwhen using Clang, but restrict it to Linux (uname_S== Linux). This suppresses the warning for glibc headers while keeping the build strict on other platforms (like macOS) to catch accidental C11 usage in Git's own code.Signed-off-by Shnatu <[email protected]>---
config.mak.dev: suppress C11 extension warning for Clang on LinuxPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2291%2Fkiranani%2Fnext-2-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2291/kiranani/next-2-v1
Pull-Request: https://github.com/git/git/pull/2291config.mak.dev | 3 +++ 1 file changed, 3 insertions(+)config.mak.dev +3
-0@@ -87,6 +87,9 @@ endif # The bug was fixed in Apple clang 12. # ifneq ($(filter clang1,$(COMPILER_FEATURES)),) # if we are using clang +ifeq ($(uname_S),Linux) +DEVELOPER_CFLAGS += -Wno-c11-extensions +endif ifeq ($(uname_S),Darwin) # if we are on darwin ifeq ($(filter clang12,$(COMPILER_FEATURES)),) # if version < 12 DEVELOPER_CFLAGS += -Wno-missing-bracesbase-commit:
4f69b47b940100b02630f745a52f9d9850f122b2--
gitgitgadget