Summary says all, for tracking purposes. qt5-qtwebengine fails similarly, bug #1545918 , so if you have any insights, please do share
So I've got a traceback, at least. Highlight: Thread 1 (Thread 0x7ffff7fe5740 (LWP 2259)): #0 __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:427 No locals. #1 0x00000000004f0b2e in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*> (this=0xb86268, __beg=0xb65fa0 " k\270", __end=0x16cb890 <error: Cannot access memory at address 0x16cb890>) at /usr/include/c++/8/bits/basic_string.tcc:225 __dnew = 11950320 #2 0x00000000005dc82f in SourceFile::SourceFile (this=0xb86268) at /builddir/build/BUILD/chromium-64.0.3282.167/tools/gn/source_file.h:22 No locals. #3 0x0000000000622031 in std::_Head_base<3ul, SourceFile, false>::_Head_base (this=0xb86268, __h=...) at /usr/include/c++/8/tuple:126 No locals. #4 0x0000000000621f55 in std::_Tuple_impl<3ul, SourceFile, InputFile*>::_Tuple_impl<SourceFile const&, InputFile*, void> (this=0xb86260, __head=...) at /usr/include/c++/8/tuple:218 No locals. #5 0x0000000000621d44 in std::_Tuple_impl<2ul, BuildSettings const*, SourceFile, InputFile*>::_Tuple_impl<BuildSettings const*&, SourceFile const&, InputFile*, void> (this=0xb86260, __head=@0x7fffffffcdd8: 0xb63770) at /usr/include/c++/8/tuple:218 No locals. #6 0x0000000000621a3c in std::_Tuple_impl<1ul, LocationRange, BuildSettings const*, SourceFile, InputFile*>::_Tuple_impl<LocationRange const&, BuildSettings const*&, SourceFile const&, InputFile*, void> (this=0xb86260, __head=...) at /usr/include/c++/8/tuple:218 No locals. #7 0x000000000062151a in std::_Tuple_impl<0ul, scoped_refptr<InputFileManager>, LocationRange, BuildSettings const*, SourceFile, InputFile*>::_Tuple_impl<InputFileManager*, LocationRange const&, BuildSettings const*&, SourceFile const&, InputFile*, void> (this=0xb86260, __head=@0x7fffffffce38: 0xb658f0) at /usr/include/c++/8/tuple:218 No locals. #8 0x0000000000620b14 in std::tuple<scoped_refptr<InputFileManager>, LocationRange, BuildSettings const*, SourceFile, InputFile*>::tuple<InputFileManager*, LocationRange const&, BuildSettings const*&, SourceFile const&, InputFile*, true> (this=0xb86260) at /usr/include/c++/8/tuple:647 No locals. Will attach the full thing. I got this by attempting a build in a mock chroot, then accessing the mock chroot and running (from the build directory): tools/gn/bootstrap/bootstrap.py -v -d --no-clean --gn-gen-args ' is_debug=false system_libdir="lib64" google_api_key="AIzaSyDUIXvzVrt5OkVsgXhQ6NFfvWlA44by-aw" google_default_client_id="449907151817.apps.googleusercontent.com" google_default_client_secret="miEreAep8nuvTdvLums6qyLK" is_clang=false use_sysroot=false use_gold=false fieldtrial_testing_like_official_build=true ffmpeg_branding="Chromium" proprietary_codecs=false treat_warnings_as_errors=false linux_use_bundled_binutils=false use_custom_libcxx=false use_gio=true use_pulseaudio=true icu_use_data_file=true enable_nacl=false is_component_ffmpeg=true is_component_build=true remove_webcore_debug_symbols=true enable_hangout_services_extension=true use_aura=true enable_webrtc=true enable_widevine=true use_gtk3=true' that's the same bootstrap.py command that the package build runs, but with '-d' (for debugging symbols) and '--no-clean' (so it doesn't build in a temp dir and clean it up on failure). When that fails, you can now run the actual failing command through gdb: gdb /builddir/build/BUILD/chromium-64.0.3282.167/out_bootstrap/gn (gdb) run gen /builddir/build/BUILD/chromium-64.0.3282.167/out/Debug --args='is_debug=false system_libdir="lib64" google_api_key="AIzaSyDUIXvzVrt5OkVsgXhQ6NFfvWlA44by-aw" google_default_client_id="449907151817.apps.googleusercontent.com" google_default_client_secret="miEreAep8nuvTdvLums6qyLK" is_clang=false use_sysroot=false use_gold=false fieldtrial_testing_like_official_build=true ffmpeg_branding="Chromium" proprietary_codecs=false treat_warnings_as_errors=false linux_use_bundled_binutils=false use_custom_libcxx=false use_gio=true use_pulseaudio=true icu_use_data_file=true enable_nacl=false is_component_ffmpeg=true is_component_build=true remove_webcore_debug_symbols=true enable_hangout_services_extension=true use_aura=true enable_webrtc=true enable_widevine=true use_gtk3=true' and, bingo. Proposing as a Beta blocker as the failure in qt5-qtwebengine is effectively blocking composes ATM; that package needs rebuilding for new libevent but cannot be rebuilt due to this bug, and that prevents the KDE x86_64 live image from composing.
Created attachment 1396785 [details] traceback from the failed 'gn' attempt
For the record, qt5-qtwebengine needs to be rebuilt for Qt 5.10.1, too. But it doesn't really matter for how many reasons it needs to be rebuilt. :-)
For the record, Adam filed a bug upstream yesterday: https://bugs.chromium.org/p/chromium/issues/detail?id=812877 I took a look today, and believe it's a regression in GCC (see comment #10 there).
That's what I immediately thought, too, and your disassembly comparison pretty much proves it. I am filing a bug against GCC.
This no longer needs to block Beta, as qt5-qtwebengine has been rebuilt and Rawhide composes are now unblocked. However, Chromium itself does not build, even with the workaround we applied to qt5-qtwebengine (-fabi-version=11) - that gets it past the gn compile error, and the x86_64 and i686 builds succeeded, but aarch64 failed later on: ../../third_party/breakpad/breakpad/src/client/linux/handler/exception_handler.cc:458:52: error: 'struct mcontext_t' has no member named '__glibc_reserved1'; did you mean '__reserved'? https://koji.fedoraproject.org/koji/taskinfo?taskID=25101544 So, we still need this bug open.
That's an issue in the Google Breakpad crash handler, which QtWebEngine does not use, so no wonder we are not seeing that build failure in it. It looks like Breakpad is poking around in glibc internals that changed in the latest glibc.
(In reply to Adam Williamson from comment #6) > ../../third_party/breakpad/breakpad/src/client/linux/handler/ > exception_handler.cc:458:52: error: 'struct mcontext_t' has no member named > '__glibc_reserved1'; did you mean '__reserved'? This is actually coming from chromium-63.0.3289.84-aarch64-glibc-2.26.90.patch
That patch should probably just be dropped.
I'll try a build without it, since spot still doesn't seem to be around. Thanks, folks. (this is one of those cases where I wake up in two years with a headache wondering when the hell I became the chromium maintainer, isn't it? I don't even *use* chromium...)
Update: spot is around, just hadn't had time to comment on the bug yet: he has a build going in Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=25165606 with the fabi-version workaround and the patch Kevin noticed dropped. (Also, bumps to a newer upstream release).
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.