summaryrefslogtreecommitdiff
path: root/vcl/Library_vcl.mk
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2020-09-25 10:01:11 +0200
committerStephan Bergmann <sbergman@redhat.com>2020-09-25 11:36:39 +0200
commit40c731726b583cdb3a8884e90f17637f35aa3ef8 (patch)
treea3c5071e25d059a826cc01ad6e70a3b82ecd9b61 /vcl/Library_vcl.mk
parent9a0d564dd949e09a15b16e9926f1631ac076e548 (diff)
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>
Diffstat (limited to 'vcl/Library_vcl.mk')
0 files changed, 0 insertions, 0 deletions