Summary: | sys-devel/clang: doesn't include <stdc-predef.h> (dev-libs/libedit: fails to compile with Clang 15 (and musl?) (error: wchar_t must store ISO 10646 characters)) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sam James <sam> |
Component: | Current packages | Assignee: | LLVM support project <llvm> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arsen, eike.beyer, mgorny, srcshelton |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://reviews.llvm.org/D34158 https://reviews.llvm.org/D106577 https://reviews.llvm.org/D137043 https://bugs.gentoo.org/show_bug.cgi?id=560228 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 408963, 430702 | ||
Attachments: | build.log |
Description
Sam James
2022-09-13 18:09:45 UTC
Arsen helped dig into this and the issue is that Clang never ends up getting #include <stdc-predef.h> on e.g. musl systems. On glibc systems, it's fine, because /usr/include/features.h contains it. See: - https://www.openwall.com/lists/musl/2021/04/16/8 - https://reviews.llvm.org/D34158 - https://reviews.llvm.org/D106577 I'm a bit confused how this works, to be honest. FWICS on glibc targets, GCC preincludes <stdc-predef.h>. However, this seems specific to glibc -- so do we patch GCC on musl to do that as well, or does this rule get applied to musl target as well? Furthermore, glibc has the <features.h> fallback-include for this file. Since clang doesn't do what GCC does, apparently it relies on this fallback on glibc systems. Now, FWICS musl also includes such a file and expects the compiler to preinclude it. However, it does not include the fallback which basically means that it's going to cause issues on every compiler that doesn't preinclude it. From the linked threads I can only establish the following: - musl upstream shifts blame to clang (so effectively every compiler that doesn't follow some magic code?) - the original patch to include <stdc-predef.h> in clang got reverted because of some test failures and because apparently "it broke chromium build", with no info how it was broken and no reply to the questions asked there - the newer patch to define the macro directly got stuck on some standards-related discussion, and is waiting "to hear back" for a year now So we're basically stuck between people throwing blame around and not caring at all about user systems working. (In reply to Michał Górny from comment #2) > I'm a bit confused how this works, to be honest. See gccint link below. > FWICS on glibc targets, GCC preincludes <stdc-predef.h>. However, this > seems specific to glibc -- so do we patch GCC on musl to do that as well, or > does this rule get applied to musl target as well? It's fine on Alpine: / # gcc -E -x c - </dev/null # 0 "<stdin>" # 0 "<built-in>" # 0 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 0 "<command-line>" 2 # 1 "<stdin>" / # cat /etc/os-release NAME="Alpine Linux" ... and with Crossdev: [i] ~$ </dev/null x86_64-linux-musl-gcc -E -x c - # 0 "<stdin>" # 0 "<built-in>" # 0 "<command-line>" # 1 "/usr/x86_64-linux-musl/usr/include/stdc-predef.h" 1 3 4 # 0 "<command-line>" 2 # 1 "<stdin>" [i] ~$ Though, I can't quite discern why (I could give looking at it throughly another try later, if so desired). > Now, FWICS musl also includes such a file and expects the compiler to > preinclude it. However, it does not include the fallback which basically > means that it's going to cause issues on every compiler that doesn't > preinclude it. > > From the linked threads I can only establish the following: > > - musl upstream shifts blame to clang (so effectively every compiler that > doesn't follow some magic code?) The protocol for this falls into the libc<->compiler category and is pretty simple: put a header somewhere (and tell the compiler about it) so that macros that are supposed to be predefined are predefined. Glibc, as always, has a workaround for misbehaving compilers, but this shouldn't be needed ultimately. IMO, this is a compiler concern. GCC does this per-target via a hook in gcc/gcc/config (see https://gcc.gnu.org/onlinedocs/gccint/Misc.html#index-TARGET_005fC_005fPREINCLUDE), and Clang could pretty easily do a similar/equivalent thing. A solution we could adopt between now and when Clang solves this issue is via -include in the config file. PS: I'm not certain, but, if I had to guess, the Chromium build broke because Bionic didn't have the predef header or something, or Chromium relied on a macro in there to do some fixup. To be clear, workaround for now until it's fixed upstream in LLVM: Add '-include stdc-predef.h' (no quotes around it) to /etc/clang/default.cfg on a new line. (In reply to Sam James from comment #4) > To be clear, workaround for now until it's fixed upstream in LLVM: > > Add '-include stdc-predef.h' (no quotes around it) to /etc/clang/default.cfg > on a new line. meowray points out: this should be /etc/clang/clang.cfg nowadays. I was unable to build sys-kernel/gentoo-kernel-6.1.11 with the clang.cfg patch applied: commenting it out fixed the build issue of "<built-in>:2:10: fatal error: 'stdc-predef.h' file not found" I get the same on clang16+musl ~$ clang -nostdinc -include stdc-predef.h -E -x c - <<<'' # 1 "<stdin>" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 375 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "/usr/include/gentoo/fortify.h" 1 # 2 "<built-in>" 2 <built-in>:2:10: fatal error: 'stdc-predef.h' file not found #include "stdc-predef.h" ^~~~~~~~~~~~~~~ # 1 "<stdin>" 2 1 error generated. ~ 1 $ Annoying... GCC, of course, does the same thing, but -nostdinc disables this include for GCC: ~$ gcc -E -x c - <<<'' # 0 "<stdin>" # 0 "<built-in>" # 0 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 0 "<command-line>" 2 # 1 "<stdin>" ~$ gcc -nostdinc -E -x c - <<<'' # 0 "<stdin>" # 0 "<built-in>" # 0 "<command-line>" # 1 "<stdin>" ~$ Does this config parser have some conditional support, or something? I forgot, I had a hack for this which I gave immolo last week. We can use __has_include and when -nostdinc, it'll fail - similar to the FORTIFY_SOURCE hack we do in /usr/include/gentoo/fortify.h. ``` /* __has_include is an extension, but it's fine, because this is only for Clang anyway. */ #if defined __has_include && __has_include (<stdc-predef.h>) # include <stdc-predef.h> #endif ``` then -include /usr/include/gentoo/maybe-stddefs.h in clang.cfg. That seems OK. *** Bug 904696 has been marked as a duplicate of this bug. *** I'll chuck this in later then, I'd forgot we hadn't. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=14dd0724ad00c2968202e46b4fc11f6f18cb440f commit 14dd0724ad00c2968202e46b4fc11f6f18cb440f Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-16 23:11:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-16 23:11:59 +0000 sys-devel/clang-common: add maybe-stddefs.h helper This is needed for musl (and any non-glibc target actually) with Clang, as GCC adds it by itself (but glibc covers for the compiler even if it doesn't), but neither Clang nor musl include it by themselves. See also: - https://www.openwall.com/lists/musl/2021/04/16/8 - https://reviews.llvm.org/D34158 - https://reviews.llvm.org/D106577 - https://reviews.llvm.org/D137043 Closes: https://bugs.gentoo.org/870001 Signed-off-by: Sam James <sam@gentoo.org> .../clang-common/clang-common-16.0.3-r1.ebuild | 190 +++++++++++++++++++++ .../clang-common/clang-common-16.0.4.9999.ebuild | 10 ++ .../clang-common/clang-common-17.0.0.9999.ebuild | 10 ++ .../clang-common-17.0.0_pre20230502.ebuild | 10 ++ .../clang-common-17.0.0_pre20230512.ebuild | 10 ++ 5 files changed, 230 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d3dbcb7be81dae3816aff400f7461beba4ddb22 commit 3d3dbcb7be81dae3816aff400f7461beba4ddb22 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-16 23:17:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-16 23:17:29 +0000 sys-devel/clang-common: add __GLIBC__ guard to maybe-stddefs.h too It should be fine without this, but we know glibc has a safeguard to make sure it's included, so let's not interfere there. Bug: https://bugs.gentoo.org/870001 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/clang-common/clang-common-16.0.3-r1.ebuild | 2 +- sys-devel/clang-common/clang-common-16.0.4.9999.ebuild | 2 +- sys-devel/clang-common/clang-common-17.0.0.9999.ebuild | 2 +- sys-devel/clang-common/clang-common-17.0.0_pre20230502.ebuild | 2 +- sys-devel/clang-common/clang-common-17.0.0_pre20230512.ebuild | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c87fedc1002c0bb9971c07eb4937733b18533ebc commit c87fedc1002c0bb9971c07eb4937733b18533ebc Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-27 07:28:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-27 07:30:30 +0000 sys-devel/clang-common: backport maybe-stddefs to 15.x Closes: https://bugs.gentoo.org/870001 Signed-off-by: Sam James <sam@gentoo.org> .../clang-common/clang-common-15.0.7-r6.ebuild | 185 +++++++++++++++++++++ 1 file changed, 185 insertions(+) |