mozconfig-v6.48.eclass puts into .mozconfig --target=armv7a-hardfloat-linux-musleabi leading in the configure phase to checking for host system type... armv7l-unknown-linux-gnueabihf checking for target system type... armv7a-hardfloat-linux-musleabi checking whether cross compiling... yes and not surprisingly soon to a build failure. The relevant section in mozconfig-v6.48.eclass is commented with # Instead of the standard --build= and --host=, mozilla uses --host instead # of --build, and --target intstead of --host. # Note, mozilla also has --build but it does not do what you think it does. but this comment seems to be outdated. After patching the eclass to switch back --host to --build and --target to --host the configure phase looks better: checking for host system type... armv7a-hardfloat-linux-musleabi checking for target system type... armv7a-hardfloat-linux-musleabi checking whether cross compiling... no I have not tested actual cross-compilation.
I can put the assignment of --build back (at least for the non-cross-compile version), but the notes in those comments are accurate and current. Upstream explicitly said that --build should not be set. Could you please attach the full build.log? Since it apparently fails a short time after, hopefully it does not even need to be compressed.
Created attachment 442546 [details] build.log
(In reply to Felix Janda from comment #2) > Created attachment 442546 [details] > build.log ...does this happen on successful builds? psutil/_psutil_linux.c: In function 'psutil_net_if_stats': psutil/_psutil_linux.c:520:21: error: 'caddr_t' undeclared (first use in this function) ifr.ifr_data = (caddr_t)ðcmd; ^~~~~~~ psutil/_psutil_linux.c:520:21: note: each undeclared identifier is reported only once for each function it appears in error: command 'armv7a-hardfloat-linux-musleabi-gcc' failed with exit status 1 I know it says that it continues due to being optional, but i'm pretty sure that it's actually needed. Especially given that your show-stopper error is related to the following call failing: /mnt/a/tmp/portage/www-client/firefox-48.0/work/firefox-48.0/ff/_virtualenv/bin/python /mnt/a/tmp/portage/www-client/firefox-48.0/work/firefox-48.0/config/expandlibs_exec.py --extract -- : crs libmemory_mozalloc.a Unified_cpp_memory_mozalloc0.o At any rate, the value that the firefox build system should pick up for host SHOULD be based on the HOST_CC and HOST_CXX values that are set in mozcoreconf-v4.eclass earlier on; these are assigned to the value from $(tc-getBUILD_CC). Is there any chance that your portage config has that string for CBUILD or anything?
The caddr_t thing is musl related and fixed upstream in https://github.com/giampaolo/psutil/commit/998ceccf9371bc13ec095c5b2941968971dfe33a (This warning was also already there for 47.0.) ':' is what configure' result for AR... js/src> checking for armv7a-linux-musleabi-ar... :
(In reply to Felix Janda from comment #4) > The caddr_t thing is musl related and fixed upstream in > > https://github.com/giampaolo/psutil/commit/ > 998ceccf9371bc13ec095c5b2941968971dfe33a > > (This warning was also already there for 47.0.) > > > ':' is what configure' result for AR... > > js/src> checking for armv7a-linux-musleabi-ar... : OK well that would do it -- executing ": [rest of command]" is effectively a no-op, and so the file it's supposed to extract from the lib would therefore not exist. Why is AR empty (or rather, ':')? Do I need to set an AR=$(tc-getAR) in the ebuild/mozcoreconf.eclass as well?
':' is the default for AR when nothing is found. Maybe the script is searching for armv7l-unknown-linux-gnueabihf-ar while saying it is searching for armv7a-hardfloat-linux-musleabi-ar. I've tested that configure indeed does not accept --build. The correct thing to do seems to be to set --host and --target when cross-compiling, and only --host else. On x86 and amd64 glibc everything has worked fine because the guessed --host coincides with the given --target.
(In reply to Felix Janda from comment #6) > ':' is the default for AR when nothing is found. Maybe the script is > searching for armv7l-unknown-linux-gnueabihf-ar while saying it is searching > for armv7a-hardfloat-linux-musleabi-ar. > > I've tested that configure indeed does not accept --build. > The correct thing to do seems to be to set --host and --target when > cross-compiling, and only --host else. > > On x86 and amd64 glibc everything has worked fine because the guessed --host > coincides with the given --target. According to upstream, --host is only supposed to be touched when it differs from --target, and --target is the one that should be set. Well actually, according to upstream they should always be left untouched unless you're cross-compiling, because the build system is omnipotent and should always find the right settings. :) That said, the reason it works on x86 and amd64 (and ppc when i tried it there) is because I'm assigning HOST_CC and HOST_CXX in mozcoreconf; otherwise it will actually report 'x86_64-unknown-linux-whatever' and 'cross-compile=yes' similarly to what you see. I'll do some experimenting though to see if setting --host in all cases does indeed work fine now (mozilla has switched to a mostly-python build system, things may have changed). For your specific failure, though, try setting AR?
In js/src/configure also as, strip and ranlib are not detected... In bug 585560 we actually have a build log for the same CHOST but for version 47.0. It seems that also there the configure script is wrongly detecting cross-compilation, but the js/src configure stage goes much better. The main difference seems to be that the "--host=armv7l-unknown-linux-gnueabihf" flag is not passed to js/src/configure in version 47.0.
Created attachment 442638 [details] configure phase when --host is passed instead of --target
Created attachment 443782 [details] build log for amd64
I have a hassle with configure failure on my amd64 unit,see build log
@Comment 10: This is a different bug, which should be reported separately. It might be possible to work around it by enabling USE=ssl for python.
Thanks for fixing this with commit 605002e1116b8eb3b37d572eefc8372bd4cbcfe9 !
