mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

external/icu: Fix #include <numbers> under --with-latest-c++ -std=c++20

Browse Source 
Not sure why I started to get that failure exactly now, but with
--with-latest-c++ enabling -std=c++20, builds with GCC (at least GCC 11 trunk)
on Fedora 32 now failed with

> In file included from ~/gcc/trunk/inst/include/c++/11.0.0/bits/max_size_type.h:37,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_base.h:38,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/string_view:44,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/bits/basic_string.h:48,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/string:55,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/bits/locale_classes.h:40,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ios_base.h:41,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/streambuf:41,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/bits/streambuf_iterator.h:35,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/iterator:66,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_algobase.h:36,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/bits/ranges_uninitialized.h:36,
>                  from ~/gcc/trunk/inst/include/c++/11.0.0/memory:69,
>                  from ../common/unicode/localpointer.h:45,
>                  from ../common/unicode/uenum.h:23,
>                  from ../common/unicode/ucnv.h:53,
>                  from unicode/ustdio.h:31,
>                  from ufile.cpp:32:
> ~/gcc/trunk/inst/include/c++/11.0.0/numbers:139:9: error: unable to find numeric literal operator ‘operator""Q’
>   139 |       = 2.718281828459045235360287471352662498Q;
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~/gcc/trunk/inst/include/c++/11.0.0/numbers:139:9: note: use ‘-fext-numeric-literals’ to enable more built-in suffixes

etc.  But the reason to #undef __STRICT_ANSI__ (which is set by -std=c++... vs.
-std=gnu++...) in workdir/UnpackedTarball/icu/source/io/ufile.cpp appears to be
obsolete, at least on Fedora 32 <stdio.h> does declare fileno (which is a POSIX
extension) under -std=c++... just fine.

Change-Id: I3707418db56d7fe9946655ab27bf1bf8eb479a1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103371
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This commit is contained in:
Stephan Bergmann
2020-09-25 10:01:11 +02:00
parent 9a0d564dd9
commit 40c731726b
2 changed files with 16 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
external/icu/UnpackedTarball_icu.mk vendored
View File

@@ -39,6 +39,7 @@ $(eval $(call gb_UnpackedTarball_add_patches,icu,\
external/icu/ubsan.patch \
external/icu/Wdeprecated-copy-dtor.patch \
external/icu/icu4c-khmerbreakengine.patch.1 \
external/icu/strict_ansi.patch \
))
$(eval $(call gb_UnpackedTarball_add_file,icu,source/data/brkitr/khmerdict.dict,external/icu/khmerdict.dict))

15
external/icu/strict_ansi.patch vendored Normal file
View File

@@ -0,0 +1,15 @@
--- source/io/ufile.cpp
+++ source/io/ufile.cpp
@@ -21,12 +21,6 @@
*/
#include "unicode/platform.h"
-#if defined(__GNUC__) && !defined(__clang__) && defined(__STRICT_ANSI__)
-// g++, fileno isn't defined if __STRICT_ANSI__ is defined.
-// clang fails to compile the <string> header unless __STRICT_ANSI__ is defined.
-// __GNUC__ is set by both gcc and clang.
-#undef __STRICT_ANSI__
-#endif
#include "locmap.h"
#include "unicode/ustdio.h"