On Thu, 2025-03-13 at 14:53 +0000, Jonathan Wakely wrote: > On Tue, 11 Feb 2025 at 22:44, Sérgio Basto <ser...@serjux.com> wrote: > > > > On Tue, 2025-02-11 at 21:45 +0000, Jonathan Wakely wrote: > > > On Tue, 28 Jan 2025 at 09:07, Jakub Jelinek <ja...@redhat.com> > > > wrote: > > > > > > > > On Mon, Jan 27, 2025 at 07:31:35PM +0000, Sérgio Basto via > > > > devel > > > > wrote: > > > > > I just want check, if I'm thinking correctly before > > > > > submitting a > > > > > fix in > > > > > gtest package > > > > > > > > > > The problem is on Rawhide I have this warning that make other > > > > > packages > > > > > fail to build [1] > > > > > > > > > > gtest source [2] source get __cplusplus value and include > > > > > <version> or > > > > > #include <ciso646> depending on __cplusplus value . > > > > > > > > > > On rawhide I got the warning on Fedora 41 don't but > > > > > __cplusplus > > > > > of GCC > > > > > compiler is the same (201703) > > > > > > > > > > My proposal is to change the comparison from 202002L to > > > > > 201703L > > > > > -#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > > > > > +#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > > > > > > > > That is not correct. <version> is actually not guaranteed to > > > > be > > > > there for > > > > C++17, it was only added in https://wg21.link/p0754r2 in 2018 > > > > (so > > > > e.g. for > > > > GCC since GCC 9.1). __has_include is supported by GCC since > > > > 2014 > > > > (so GCC > > > > 5.1). So your change would break building with GCC 5.1 to 8.5. > > > > I think if it did e.g. > > > > #if (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > > > > !defined(__has_include)) || \ > > > > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > > > > GTEST_INTERNAL_HAS_INCLUDE(<version>)) > > > > #include <version> > > > > #endif > > > > it would be better, C++20 should guarantee there is <version> > > > > (but > > > > also > > > > that __has_include is there, but this stuff attempts to cover > > > > also > > > > the cases > > > > of the incremental development of the standard features). > > > > I don't really see the point of including <ciso646>, it is a > > > > useless header > > > > which doesn't contain anything since its introduction and has > > > > been > > > > removed > > > > without deprecation in C++20. > > > > I think the rationale some people give is that it is the > > > > smallest > > > > C++ header > > > > (contains nothing) which still includes some basic header with > > > > some > > > > macros > > > > (in the libstdc++ case it is <bits/c++config.h>, in libcxx case > > > > it > > > > is > > > > <__config>). But e.g. in the libstdc++ case, that header > > > > doesn't > > > > really > > > > define any feature test macros, the __cpp_* macros are > > > > predefined > > > > by the > > > > compiler and __cpp_lib_* are defined by the individual headers > > > > which provide > > > > that functionality or (when it exists) in <version>. > > > > > > "Traditionally" <ciso646> was included to find out which C++ > > > standard > > > library implementation you were using, by including it and then > > > checking for _LIBCPP_VERSION or _GLIBCXX_VERSION. > > > > > > So it's not supposed to be used for checking the standard > > > __cpp_lib_xxx macros, but the implementation-specific ones. > > > > > > N.B. GCC's <ciso646> did not actually define _GLIBCXX_VERSION (or > > > any > > > other libstdc++ macros) until GCC 6.1, because it really did > > > _nothing_ > > > before that. It didn't even include <bits/c++config.h>. > > > > > > I second Jakub's suggestion to just include <version> if it's > > > available. It's not required by the C++ standard until C++20, but > > > given a sufficiently new compiler the <version> header is still > > > present and can be included for older versions of C++. > > > > > > > Hi, but if we are build in an "old" GCC , can we replace <ciso646> > > by > > <cerrno> ? I also like the Jakub's suggestion [1] . Should/Can we > > apply this suggestion also to abseil-cpp-20240722.1 ? > > > > [1] > > #if GTEST_INTERNAL_HAS_INCLUDE(<version>) || \ > > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && > > !defined(__has_include)) > > #include <version> // C++20 and later > > #else > > #include <cerrno> // Pre-C++20 > > #endif > > > I missed this follow-up question, sorry. Including <cerrno> would > have > equivalent effects to <ciso606>, except for also declaring all the > contents of <errno.h> (which isn't very much, so mostly harmless). > > Before GCC 6.1 <cerrno> did not define the _GLIBCXX_xxx macros, but > neither did <ciso646> so there's no difference between then in that > respect. >
OK, I will check if maintainer of the package in question want apply this solution IIRC, I disabled warnings being treated as errors ... Thank you , -- Sérgio M. B. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
