91:16.49 <inline asm>:5:13: error: Could not find incbin file 'icudt67l.dat' 91:16.49 .incbin "icudt67l.dat" 91:16.49 ^ 91:16.49 LLVM ERROR: Error parsing inline asm 91:16.49 #0 0x00007f711a33890a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x92690a) 91:16.49 #1 0x00007f711a3368b4 llvm::sys::RunSignalHandlers() (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x9248b4) 91:16.49 #2 0x00007f711a337435 (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x925435) 91:16.49 #3 0x00007f71199d8080 __restore_rt (/lib64/libpthread.so.0+0x13080) 91:16.49 #4 0x00007f711acaad89 llvm::BitcodeModule::getModuleImpl(llvm::LLVMContext&, bool, bool, bool) (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x1298d89) 91:16.49 #5 0x00007f711acac579 llvm::BitcodeModule::parseModule(llvm::LLVMContext&) (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x129a579) 91:16.49 #6 0x00007f711b7b2639 (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x1da0639) 91:16.50 #7 0x00007f711a2d63d5 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::__future_base::_Task_state<std::function<void ()>, std::allocator<int>, void ()>::_M_run()::'lambda'(), void> >::_M_invoke(std::_Any_data const&) (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x8c43d5) 91:16.50 #8 0x00007f711a2bce09 (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x8aae09) 91:16.50 #9 0x00007f71199d52a7 __pthread_once_slow (/lib64/libpthread.so.0+0x102a7) 91:16.50 #10 0x00007f711a2d78b4 void std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x8c58b4) 91:16.50 #11 0x00007f711a2d953d (/usr/lib/llvm/10/lib64/libLLVM-10.so+0x8c753d) 91:16.50 #12 0x00007f711985653f (/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/libstdc++.so.6+0xfc53f) 91:16.50 #13 0x00007f71199cce67 start_thread (/lib64/libpthread.so.0+0x7e67) 91:16.50 #14 0x00007f7119698dbf clone (/lib64/libc.so.6+0xf8dbf) 91:16.50 clang-10: error: unable to execute command: Segmentation fault 91:16.50 clang-10: error: linker command failed due to signal (use -v to see invocation) 91:16.50 gmake[4]: *** [/var/tmp/portage/www-client/firefox-78.0.1-r1/work/firefox-78.0.1/config/rules.mk:606: libxul.so] Error 254 91:16.50 gmake[4]: Leaving directory '/var/tmp/portage/www-client/firefox-78.0.1-r1/work/firefox-78.0.1/ff/toolkit/library/build' 91:16.50 gmake[3]: *** [/var/tmp/portage/www-client/firefox-78.0.1-r1/work/firefox-78.0.1/config/recurse.mk:74: toolkit/library/build/target] Error 2 91:16.50 gmake[2]: *** [/var/tmp/portage/www-client/firefox-78.0.1-r1/work/firefox-78.0.1/config/recurse.mk:34: compile] Error 2 91:16.50 gmake[1]: *** [/var/tmp/portage/www-client/firefox-78.0.1-r1/work/firefox-78.0.1/config/rules.mk:390: default] Error 2 91:16.50 gmake: *** [client.mk:125: build] Error 2 91:16.50 193 compiler warnings present. * ERROR: www-client/firefox-78.0.1-r1::gentoo failed (compile phase): * Failed to run './mach build --verbose' * * Call stack: * ebuild.sh, line 125: Called src_compile * environment, line 5343: Called virtx './mach' 'build' '--verbose' * environment, line 6826: Called die * The specific snippet of code: * [[ ${retval} -ne 0 ]] && die "Failed to run '$@'"; Reproducible: Always Steps to Reproduce: 1. emerge -v firefox Actual Results: It fails to build Expected Results: It should build, r0 did.
Created attachment 648346 [details] emerge --info
Created attachment 648348 [details] build.log
Same here. But some differences with USE-Flags -custom-flags -custom-optimization -pgo -screenshot +system-libvpx -wayland -wifi (? not mentioned in his build-log) others are the same. Errormessages exactly indentical.
can please both of you paste your emerge -pv firefox stuff here?
(In reply to tt_1 from comment #4) > can please both of you paste your emerge -pv firefox stuff here? emerge -vp firefox These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] www-client/firefox-78.0.1-r1::gentoo [78.0.1::gentoo] USE="clang custom-cflags custom-optimization gmp-autoupdate lto openh264 pgo pulseaudio screenshot system-av1 system-harfbuzz system-jpeg system-libevent system-webp wayland -bindist -debug -eme-free -geckodriver -hardened -hwaccel -jack (-selinux) -system-icu -system-libvpx -test -wifi" CPU_FLAGS_X86="avx2" L10N="de -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -cak -cs -cy -da -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -ur -uz -vi -xh -zh-CN -zh-TW" 327.271 KiB
to me it seems obvious that there's something in the bush about system-icu, since you don't use it and the patchlevel bump had two or three new patches dealing with icu support. also the error message is more about a missing file from icu, and less about how clang-10 chokes without finding it might be worth to try +system-icu I may try out your combination without pgo if I can find some spare cpu cycles for that
On my (recent) system -r1 does not compile on gcc-10.1.0-r2 p3 with distcc. [ebuild U ] www-client/firefox-78.0.1-r1::gentoo [78.0.1::gentoo] USE="custom-cflags custom-optimization gmp-autoupdate hwaccel openh264 pulseaudio screenshot system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp wayland -bindist -clang -debug -eme-free -geckodriver -hardened -jack -lto -pgo (-selinux) -test -wifi" And I cannot find exact reason - only warnings and "proxy errors" in build.log. I switched to gcc after I cannot compile FF on Clang-10...
Have the same problem. In my case clang dies with a segfault though: 160:43.22 <inline asm>:5:13: error: Could not find incbin file 'icudt67l.dat' 160:43.22 .incbin "icudt67l.dat" 160:43.22 ^ 160:43.22 LLVM ERROR: Error parsing inline asm 160:43.22 clang-10: error: unable to execute command: Segmentation fault This is the -pv output: [ebuild U ] www-client/firefox-78.0.1-r1::gentoo [78.0.1::gentoo] USE="clang eme-free hwaccel lto openh264 pgo pulseaudio screenshot system-av1 system-harfbuzz system-jpeg system-libevent system-libvpx system-webp wayland wifi -bindist -custom-cflags -custom-optimization -debug -geckodriver -gmp-autoupdate -hardened -jack (-selinux) -system-icu -test" CPU_FLAGS_X86="avx2" L10N="en-GB -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -cak -cs -cy -da -de -dsb -el -en-CA -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -ur -uz -vi -xh -zh-CN -zh-TW"
Oh wait, the error is the same nvm.
(In reply to tt_1 from comment #6) > to me it seems obvious that there's something in the bush about system-icu, > since you don't use it and the patchlevel bump had two or three new patches > dealing with icu support. also the error message is more about a missing > file from icu, and less about how clang-10 chokes without finding it > > might be worth to try +system-icu > > I may try out your combination without pgo if I can find some spare cpu > cycles for that I will try to build a +system-icu (no fan) firefox later today.
Comment on attachment 648348 [details] build.log Why don't you compress that file directly? Storing it in a tar archive is entirely unneeded.
(In reply to Jeroen Roovers from comment #11) > Comment on attachment 648348 [details] > build.log > > Why don't you compress that file directly? Storing it in a tar archive is > entirely unneeded. I played a little to achieve a size below 1M. Maybe I uploaded the wrong file.
Sorry for delay. Had a closer look on all infos. First Here is what you ask for : [ebuild R ] www-client/firefox-78.0.1-r1::locolay USE="clang gmp-autoupdate lto openh264 pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp -bindist -custom-cflags -custom-optimization -debug -eme-free -geckodriver -hardened -hwaccel -jack -pgo -screenshot (-selinux) -test -wayland -wifi" CPU_FLAGS_X86="avx2" L10N="de" Secondly Sorry also for the false "me too". System-icu was unset and i did not see. I am on Funtoo but use a lot of gentoo Overlay ebuilds. Like 78.0.1-r1. Daniel masked last week in the profiles package.use.mask (for a strange reason) system-icu for chromium and firefox. He stated two gentoo guys (Pawel Hajdan jr.' and Ian Stakenvicius') notes as reason. So i uncommented that and gave it a try. Compiled very nicely now. So for me, my USE-Flags and used depending other packages everything goes right.
+system-icu build has been successful
Newer www-client/firefox-78.0.2 merges right using Clang and Clang wist distcc - I propose closing this bug.
Created attachment 649008 [details] crash in build log with lto enabled this is linked to lto+clang: [ebuild R ~] www-client/firefox-78.0.2::gentoo USE="clang eme-free hwaccel lto* openh264 pulseaudio system-harfbuzz system-jpeg system-libevent system-libvpx system-webp -bindist -custom-cflags -custom-optimization -debug -geckodriver -gmp-autoupdate -hardened -jack -pgo (-screencast) -screenshot (-selinux) -system-av1 -system-icu -test -wayland -wifi" CPU_FLAGS_X86="avx2" L10N="de -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -cak -cs -cy -da -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -ur -uz -vi -xh -zh-CN -zh-TW" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB lto+gcc was not yet tested I'm on llvm/clang/lld-10.0.1_rc4
Created attachment 649010 [details] output from emerge --info my emerge --info
Created attachment 649012 [details] crash in build log with gcc+lto enabled it also fails to find icudt67l.dat with gcc+lto and USE="-system-icu" 32:16.50 | ^ 32:16.50 /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/intl/icu/source/common/uobject.cpp: In member function 'getEquivalents': 32:16.50 /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/intl/icu/source/common/cmemory.cpp:45: note: in a call to allocation function 'uprv_malloc_67' declared here 32:16.50 45 | uprv_malloc(size_t s) { 32:16.50 | 32:16.50 In member function 'useAtomicCounterFunction', 32:16.50 inlined from 'visitAggregate' at /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/gfx/angle/checkout/src/compiler/translator/OutputHLSL.cpp:2343:0: 32:16.50 /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/gfx/angle/checkout/src/compiler/translator/ImmutableString.h:78:22: warning: '__builtin_memcmp_eq' reading 22 bytes from a region of size 1 [-Wstringop-overflow=] 32:16.50 78 | return memcmp(data(), b.data(), mLength) == 0; 32:16.50 | ^ 32:16.50 {standard input}: Assembler messages: 32:16.50 {standard input}:7212: Error: file not found: icudt67l.dat 32:16.50 In function 'operator new', 32:16.50 inlined from 'newUnicodeStringArray' at /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/intl/icu/source/common/filteredbrk.cpp:557:1, 32:16.50 inlined from 'createZoneStrings' at /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/intl/icu/source/i18n/dtfmtsym.cpp:342:54, 32:16.50 inlined from 'createZoneStrings' at /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/intl/icu/source/i18n/dtfmtsym.cpp:333:0, 32:16.50 inlined from 'copyData' at /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/intl/icu/source/i18n/dtfmtsym.cpp:431:26: 32:16.50 /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/intl/icu/source/common/uobject.cpp:62:12: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 32:16.50 62 | return uprv_malloc(size);
I think this is a good moment for the maintainer to take over, since this has most likely been introduced by these two patches: 0030-bmo-1650299-Unify-the-inclusion-of-the-ICU-data-file.patch 0031-bmo-1264836-Automatically-convert-the-little-endian-.patch and I don't understand them in their complexity. All I know is, the file in question is present: /var/tmp/portage/www-client/firefox-78.0.2/work/firefox-78.0.2/config/external/icu/data/icudt67l.dat lto is fine with either clang+gcc, as long as USE="+system-icu" is set
These are upstream patches which will land in 79.x. I am also unable to reproduce. So I am sorry but I don't know how I can help you at the moment, especially given that the problem disappeared for others. For myself I would like to understand what's making your system 'special' to trigger this...
what's more to offer than my emerge -pv firefox #16 with the failing combination of useflags and my emerge --info from #17 + the hint of my llvm/clang/lld toolchain? rust is =dev-lang/rust-1.44.1 conclusion as of now: everybody who uses lto needs to compile with system-icu
*** Bug 732528 has been marked as a duplicate of this bug. ***
I run into the same (or at least very similar) issue and opened bug 732528 (and closed it again after finding the issue here). Please see there for the attached compressed build.log file. Theres also a quick and very dirty workaround in comment 2 to get at least a working binary.
Reproduced, looking into this.
> 0031-bmo-1264836-Automatically-convert-the-little-endian-.patch I can't find an upstream patch for this. > 0030-bmo-1650299-Unify-the-inclusion-of-the-ICU-data-file.patch this is fixed in master branch, but never hasn't been backported yet to 79.0 beta branch, let alone the current 78.0 branach anyway, this bug has one regression, where people can't find the icudt67l.dat file: https://bugzilla.mozilla.org/show_bug.cgi?id=1651207 it might be a good idea to try this patch
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e4c95b8ef4e4531937f5216a17ac6ad66fe5300f commit e4c95b8ef4e4531937f5216a17ac6ad66fe5300f Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-07-14 14:02:51 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-07-14 14:06:36 +0000 www-client/firefox: unbreak USE=-system-icu Closes: https://bugs.gentoo.org/731708 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> www-client/firefox/Manifest | 2 +- www-client/firefox/firefox-78.0.2.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
Thank you for finding this one! PS: Mind sharing reasons why you don't use system's ICU?
I mostly had an academic interest in finding the problem here, since I didn't understand the two icu patches in question and it was nowhere documented. What I'm really trying to achive is to keep armv7 support alive, so I'm flipping use flags occasionally around to detect breakages. For a strange reason many of them are only exposed when enabling lto, which is the case here as well. I still don't known what > 0031-bmo-1264836-Automatically-convert-the-little-endian-.patch is all about, but guess we call it a day for now and I'm going to dig deeper into that patch later.
