Created attachment 549440 [details] compressed config log emerge -pv =firefox-60.2.2[clang] means to use clang as CC/CXX and to use ld.lld as a linker via --enable-linker=lld Now, while doing testing I found --enable-linker=bfd --enable-linker=gold to be working with clang. Looking at the build log, it seems that ld is never executed, right?
Created attachment 549442 [details] output of emerge --info emerge --info
toolchain is: rust/cargo: 1.29.1 llvm/clang/lld: 6.0.1 Now, I may test with llvm-7 toolchain, is it possible to use it for firefox-60-esr?
So the hang took around 90 minutes, there are no errors in dmesg or the build log. I don't know what do with this? Talk with upstream?
So it did not really hang, it just took 90 minutes at 100% but was successful in the end? > Now, I may test with llvm-7 toolchain, is it possible to use it for firefox-60->esr? Yes. Clang support in v60.x is the same, just no LTO support.
Technically it is a hang, as the system does nothing for a very long time, without any io out- or input, just has 100% cpu on one core With llvm/clang/lld-7 it's pretty much three hours instead of around one hour. If I can find time I may try to compile it with ebuild $(equery w firefox) install to see wether it works without problems on this lower level. But good news is: runtime testing was successfull. So its a low priority problem (to me)
This might be caused by rust-bin and llvm+clang being out of sync. My rust-bin is built with llvm-7.0, llvm/clang was on 6.0.1 back then. The hang happens also with gcc-7.3.0 as a compiler, with rust-bin of 1.32.0 and llvm-7.0.1, while a downgrade to rust-bin-1.29.2 (built with llvm-7.0) does not hang. May I ask, how does the firefox ebuild choose its python execute ./mach build with? On my workstation, it chooses python3.6 for that, while it doesn't on the arm. On both, the targets are in sync: PYTHON_TARGETS="python3_6 python2_7" PYTHON_SINGLE_TARGET="python3_6"
(In reply to tt_1 from comment #6) > This might be caused by rust-bin and llvm+clang being out of sync. My > rust-bin is built with llvm-7.0, llvm/clang was on 6.0.1 back then. > > The hang happens also with gcc-7.3.0 as a compiler, with rust-bin of 1.32.0 > and llvm-7.0.1, while a downgrade to rust-bin-1.29.2 (built with llvm-7.0) > does not hang. > > May I ask, how does the firefox ebuild choose its python execute ./mach > build with? On my workstation, it chooses python3.6 for that, while it > doesn't on the arm. On both, the targets are in sync: > > PYTHON_TARGETS="python3_6 python2_7" > PYTHON_SINGLE_TARGET="python3_6" Currently the mozilla build system needs both python2 and python3. We hard depend on python2.7 and use python-any-r1_pkg_setup() to choose the 'best' version of python3 (as python2.7 is no longer in the PYTHON_COMPAT list since it's forced). Due to the way the build system uses these variables we have to export the choice to the PYTHON3 var and then reset all the regular variables to python2 via 'python_export'. You can find the details of this at the bottom of the moz_pkg_setup() function in mozcoreconf-v6.eclass I am fairly certain that mach itself still requires python2.7, even though there are other components of the build system that uses python3.
You're obviously correct, my memory fooled me here as the emerge thread is the one using python3.6, while mach still sticks to 2.7
Closing as cantfix, its likely some obscure racing condition. Cross-compiling with gcc is the propper thing to do here.
