Bug 274041
| Summary: | lang/gcc10 lang/gcc11 lang/gcc11-devel lang/gcc12 lang/gcc12-devel lang/gcc13 lang/gcc13-devel lang/gcc14-devel: fix build with libc++ 17 | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dimitry Andric <dim> |
| Component: | Individual Port(s) | Assignee: | Lorenzo Salvadore <salvadore> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | gerald, grahamperrin |
| Priority: | --- | Flags: | salvadore:
maintainer-feedback+
|
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 273753 | ||
| Attachments: | |||
Created attachment 245147 [details]
lang/gcc10: fix build with libc++ 17
Created attachment 245148 [details]
lang/gcc11: fix build with libc++ 17
Created attachment 245149 [details]
lang/gcc11-devel: fix build with libc++ 17
Created attachment 245150 [details]
lang/gcc12: fix build with libc++ 17
Created attachment 245151 [details]
lang/gcc12-devel: fix build with libc++ 17
Created attachment 245152 [details]
lang/gcc13: fix build with libc++ 17
Created attachment 245153 [details]
lang/gcc13-devel: fix build with libc++ 17
Created attachment 245154 [details]
lang/gcc14-devel: fix build with libc++ 17
Assuming that you have tested those patches, I approve them, but please wait for an additional review from Gerald, past maintainer of the GCC ports. In particular, Gerald, do you think these patches can be easily upstreamed? Would another solution be preferable? (In reply to Lorenzo Salvadore from comment #9) Yes, I've built all gcc ports with a local poudriere here, using the world built from https://github.com/DimitryAndric/freebsd-src/tree/llvm-17-update (as described in bug 273753. As far as the actual code concerns, in https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/system.h;hb=HEAD#l197 you can see the comment: 197 /* Include <string> before "safe-ctype.h" to avoid GCC poisoning 198 the ctype macros through safe-ctype.h */ 199 200 #ifdef __cplusplus 201 #ifdef INCLUDE_STRING 202 # include <string> 203 #endif 204 #endif This was added in https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/system.h;h=33c430b50424ec31c83603616fc94671fc7ffac2 for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63699 ("Bootstrap fails in libcc1 on darwin14") and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63750 ("use of undeclared identifier 'do_not_use_isalnum_with_safe_ctype'"), which are similar bugs: * the "safe_ctype.h" header defines toupper, tolower etc so that any invocation of them results in a compile error. * at the time, including <string> *after* "safe_ctype.h" on macOS caused some parts of <ctype.h> to be transitively included, so then you got compile errors. * this also applies to FreeBSD since it uses libc++ instead of libstdc++. My proposal is that this is very fragile, since you cannot know in advance which C++ standard headers transitively include other system headers, in particular <ctype.h>, so any C++ standard header (<list>, <map>, etc) should be included before "safe-ctype.h". E.g. the only thing this patch does is move the block that includes "safe-ctype.h" to below all C++ standard header includes. This should work for all C++ environments, as far as I can tell. Btw, if it makes it easier, I can also submit an upstream bug report for this. They will probably have an opinion. :) (In reply to Lorenzo Salvadore from comment #9) > Assuming that you have tested those patches, I approve them, but > please wait for an additional review from Gerald [...] > In particular, Gerald, do you think these patches can be easily > upstreamed? Makes sense to me. My recommendation is to first push this to the -devel ports and after a good week, maybe two, the others. Re upstreaming: Definitely worth a try! I hope it does not get ignored like your "packaging" issue, Lorenzo, though for this I am more optimistic. (In reply to Dimitry Andric from comment #10) > Btw, if it makes it easier, I can also submit an upstream bug report > for this. They will probably have an opinion. :) That would be awesom, Dim. I suggest to file a bug report and in addition send a patch against HEAD to gcc-patches@gcc.gnu.org (copying me at gerald@pfeifer.com). I'll then see what I can do should this get stuck. (In reply to Gerald Pfeifer from comment #11) I submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632, and mailed the patch to gcc-patches: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631611.html A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b7833e78f7bdf5b00b5b0d25ed983f1b8d413e32 commit b7833e78f7bdf5b00b5b0d25ed983f1b8d413e32 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2023-09-21 17:49:57 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2023-10-06 17:48:53 +0000 lang/gcc10 lang/gcc11 lang/gcc11-devel lang/gcc12 lang/gcc12-devel lang/gcc13 lang/gcc13-devel lang/gcc14-devel: fix build with libc++ 17 When building relatively recent gcc ports (with C++ in them) against libc++ 17, you get errors similar to: In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/module.cc:208: In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/system.h:239: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces 546 | _LIBCPP_INLINE_VISIBILITY | ^ /usr/include/c++/v1/__config:813:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY' 813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI | ^ /usr/include/c++/v1/__config:792:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI' 792 | __attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_VERSIONED_IDENTIFIER)))) | ^ In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/module.cc:208: In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/system.h:239: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of declaration list 547 | char_type toupper(char_type __c) const | ^ /usr/include/c++/v1/__locale:553:48: error: too many arguments provided to function-like macro invocation 553 | const char_type* toupper(char_type* __low, const char_type* __high) const | ^ /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/../include/safe-ctype.h:146:9: note: macro 'toupper' defined here 146 | #define toupper(c) do_not_use_toupper_with_safe_ctype | ^ This is because gcc/system.h includes safe-ctype.h which redefines ctype macros such as toupper, tolower, etc to "poison" them. However, it should only include the safe-ctype.h header *after* any C++ headers, such as <list>, <map>, <string>, etc, otherwise these might transitively include internal ctype headers (such as with libc++ 17), causing the above conflicts. Fix it by moving the safe-ctype.h inclusion to later in gcc/system.h, which solves this issue, and makes it possible to build against libc++ 17. See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 PR: 274041 Approved by: salvadore (maintainer) MFH: 2023Q4 lang/gcc10/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ lang/gcc11-devel/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ lang/gcc11/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ lang/gcc12-devel/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ lang/gcc12/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ lang/gcc13-devel/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ lang/gcc13/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ lang/gcc14-devel/files/patch-gcc_system.h (new) | 42 +++++++++++++++++++++++++ 8 files changed, 336 insertions(+) |
When building relatively recent gcc ports (with C++ in them) against libc++ 17, you get errors similar to: In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/module.cc:208: In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/system.h:239: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces 546 | _LIBCPP_INLINE_VISIBILITY | ^ /usr/include/c++/v1/__config:813:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY' 813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI | ^ /usr/include/c++/v1/__config:792:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI' 792 | __attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_VERSIONED_IDENTIFIER)))) | ^ In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/module.cc:208: In file included from /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/system.h:239: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of declaration list 547 | char_type toupper(char_type __c) const | ^ /usr/include/c++/v1/__locale:553:48: error: too many arguments provided to function-like macro invocation 553 | const char_type* toupper(char_type* __low, const char_type* __high) const | ^ /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/../include/safe-ctype.h:146:9: note: macro 'toupper' defined here 146 | #define toupper(c) do_not_use_toupper_with_safe_ctype | ^ This is because gcc/system.h includes safe-ctype.h which redefines ctype macros such as toupper, tolower, etc to "poison" them. However, it should only include the safe-ctype.h header *after* any C++ headers, such as <list>, <map>, <string>, etc, otherwise these might transitively include internal ctype headers (such as with libc++ 17), causing the above conflicts. Here is a patch that moves the safe-ctype.h inclusion to later in gcc/system.h, which solves this issue, and makes it possible to build against libc++ 17.