Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 667786 - =www-client/firefox-60.2.2[clang] fails to emerge on arm as "python2.7 ./mach build --verbose" hangs for an infinite amount of time with 100% cpu on one core
Summary: =www-client/firefox-60.2.2[clang] fails to emerge on arm as "python2.7 ./mach...
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-05 07:31 UTC by tt_1
Modified: 2019-03-20 14:45 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
compressed config log (firefox-60.2.2-with-ldd-hangs.log.gz,232.51 KB, application/gzip)
2018-10-05 07:31 UTC, tt_1
Details
output of emerge --info (emerge-info,5.17 KB, text/plain)
2018-10-05 07:33 UTC, tt_1
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tt_1 2018-10-05 07:31:15 UTC
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?
Comment 1 tt_1 2018-10-05 07:33:05 UTC
Created attachment 549442 [details]
output of emerge --info

emerge --info
Comment 2 tt_1 2018-10-05 07:39:00 UTC
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?
Comment 3 tt_1 2018-10-05 17:02:24 UTC
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?
Comment 4 Thomas Deutschmann gentoo-dev Security 2018-10-05 19:50:23 UTC
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.
Comment 5 tt_1 2018-10-06 21:47:30 UTC
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)
Comment 6 tt_1 2019-02-14 17:42:04 UTC
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"
Comment 7 Ian Stakenvicius (RETIRED) gentoo-dev 2019-02-14 17:52:23 UTC
(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.
Comment 8 tt_1 2019-02-19 13:02:24 UTC
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
Comment 9 tt_1 2019-03-20 14:45:29 UTC
Closing as cantfix, its likely some obscure racing condition. Cross-compiling with gcc is the propper thing to do here.