On Thu, Jan 20, 2022 at 7:50 AM Kaleb Keithley <kkeit...@redhat.com> wrote:

>
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch
> --arch-override=x86_64 builds, so I tried a full build and ran into this on
> aarch64. :-(
>

ppc64le and s390x as well.


>
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> In file included from /usr/include/boost/integer.hpp:20,
>                  from /usr/include/boost/integer/integer_mask.hpp:16,
>                  from /usr/include/boost/random/mersenne_twister.hpp:26,
>                  from /usr/include/boost/uuid/random_generator.hpp:17,
>                  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>                  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>                  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>                  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>                  from 
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>                  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>                  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>                  from 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> '255' from 'int' to 'char' [-Wnarrowing]
>    83 |     public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX>
>       |
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
>
> Are we expecting an update to boost by any chance?
>
>
> On Fri, Jan 14, 2022 at 9:33 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
>> Hi!
>>
>> gcc 12 snapshot has landed as the system compiler into rawhide today.
>> GCC 12 is going to enter its stage4 development phase (only regression
>> and documentation bugfixes allowed) on Monday 17th, so there should be
>> just those bugfixes and not new features etc. anymore.
>> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
>> most important is probably that vectorization is enabled at -O2 now
>> which is the option with most of the distribution is built with.
>>
>> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
>> some cases where people need to adjust their code.  Other things
>> include the usual C++ header changes, where previously some standard
>> header included some other header as an implementation detail but it
>> doesn't
>> any longer and so code that relied on such indirect include that isn't
>> required by the standard needs to include the header that provides
>> whatever
>> it relies on.  Or e.g. packages using -Werror where new warnings are
>> reported with the newer compiler and -Werror results in build failures.
>>
>> If there are bugs on the compiler side, please let me know immediately,
>> so that those bugs can be fixed before the mass rebuild next week.
>>
>> Another important thing I wanted to say is that we'd like to switch
>> ppc64le from the numerically problematic IBM extended long double to
>> IEEE 754 quad long double.  This is an ABI change.  Some libraries
>> are already built so that they support both ABIs at the same time,
>> including glibc, libstdc++, libgcc, libgfortran etc.
>> For other libraries and binaries, the compiler, assembler and linker
>> will notice if they use long double and flag them as using either
>> IBM or IEEE long double and linker (or I think dynamic linker too)
>> might complain when things are mixed.
>> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
>> but the glibc/gcc libraries are built compatibly with both.
>> We'd like to configure gcc shortly before the mass rebuild with
>> --with-long-double-format=ieee so that it will default to
>> -mabi=ieeelongdouble, probably on a side-tag build first, and it
>> will be highly desirable to rebuild at least some of the most commonly
>> used library packages in the order of dependencies there, otherwise
>> I'd be afraid the mass rebuild could fail for way too many packages
>> (as the mass rebuild doesn't do dependency order rebuilds but just
>> goes through packages alphabetically or so).
>> Any suggestions on which packages have commonly used library packages
>> that use long double?
>> readelf -A on libraries on ppc64le prints either nothing (either
>> the library is thought not to use long double or supports both ABIs
>> transparently or hasn't been rebuilt for some years), or
>> Attribute Section: gnu
>> File Attributes
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
>> for libraries (or binaries or object files) that use IBM long double
>> only or
>> Attribute Section: gnu
>> File Attributes
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
>> for IEEE long doubles.
>> So I think we want to rebuild on a side-tag packages that
>> provide shared libraries used by hundreds of other packages that
>> are
>>   Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
>> right now.
>>
>>         Jakub
>> _______________________________________________
>> 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 on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
>
> Kaleb
>


-- 

Kaleb
_______________________________________________
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to