office-gobmx/external/icu/strict_ansi.patch
Stephan Bergmann 40c731726b external/icu: Fix #include <numbers> under --with-latest-c++ -std=c++20
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>
2020-09-25 11:36:39 +02:00

15 lines
469 B
Diff

--- 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"