Building Firefox on Linux failes

[Daniel Spannbauer]

Hello,


I try to build the Firefox 79.0 since some weeks now, with now success.


The latest build also ends with "recipe for target 'compile' failed".

I think the error is here: recipe for target 'Unified_cpp_js_src10.o' failed


What are the minimum requirements for building the Firefox? I'm building
with gcc7, which is the newest one for my target system (old Leap 42.3)

Complete Log is here:
https://build.opensuse.org/package/live_build_log/home:Marco-GmbH:42.3/MozillaFirefox/openSUSE_Leap_42.3/x86_64

Any hints?


Best regards


Daniel



--
Daniel Spannbauer Systemadministration
marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11
Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220
http://www.marco.de/ Email d...@marco.de
Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München

[ISHIKAWA,chiaki]

On 2020/09/24 16:29, Daniel Spannbauer wrote:
> Hello,
>
>
> I try to build the Firefox 79.0 since some weeks now, with now success.
>
>
> The latest build also ends with "recipe for target 'compile' failed".
>
> I think the error is here: recipe for target 'Unified_cpp_js_src10.o' failed
>
>
> What are the minimum requirements for building the Firefox? I'm building
> with gcc7, which is the newest one for my target system (old Leap 42.3)
>
> Complete Log is here:
> https://build.opensuse.org/package/live_build_log/home:Marco-GmbH:42.3/MozillaFirefox/openSUSE_Leap_42.3/x86_64
>
> Any hints?
>
>
> Best regards
>
>
> Daniel
>
>
>

This may not help much, but I am using gcc-9 for my local build of
Thunderbird from the latest comm-central branch.
(This is under Debian and I use test-repository to obtain gcc-9.)
But then, gcc-9 may have an issue or two with checking of format string
of snprintf(). It is very clever to check on the overflow when
snprintf() is used. However, at least, in Thunderbird calendar code,
there is a usage of snprintf() that triggers a bug in this feature, and
I had to patch the source locally. YMMV. At least, I don't encounter 
the spurious bug in the mozilla-central portion of the code.

It looks that your issue is related to the subtle difference of handling
of compile time constant (constexpr) between clang c++ frontend and g++'s.

---

format -Wno-shadow -Wno-attributes -MD -MP -MF .deps/Unified_cpp_js_src_jit2.o.pp Unified_cpp_js_src_jit2.cpp
[ 192s] 1:43.01 In file included from Unified_cpp_js_src10.cpp:11:0:
[ 192s] 1:43.01 /home/abuild/rpmbuild/BUILD/firefox-79.0/js/src/jsdate.cpp: In function ‘bool ParseDate(const CharT*, size_t, JS::ClippedTime*)’:
[ 192s] 1:43.01 /home/abuild/rpmbuild/BUILD/firefox-79.0/js/src/jsdate.cpp:1267:52: error: ‘constexpr size_t MinKeywordLength(const CharsAndAction (&)[N]) [with long unsigned int N = 32; size_t = long unsigned int]’ called in a constant expression
[ 192s] 1:43.01 constexpr size_t MinLength = MinKeywordLength(keywords);
[ 192s] 1:43.01 ~~~~~~~~~~~~~~~~^~~~~~~~~~
[ 192s] 1:43.01 /home/abuild/rpmbuild/BUILD/firefox-79.0/js/src/jsdate.cpp:1064:18: note: ‘constexpr size_t MinKeywordLength(const CharsAndAction (&)[N]) [with long unsigned int N = 32; size_t = long unsigned int]’ is not usable as a constexpr function because:
[ 192s] 1:43.01 constexpr size_t MinKeywordLength(const CharsAndAction (&keywords)[N]) {
[ 192s] 1:43.01 ^~~~~~~~~~~~~~~~
[ 192s] 1:43.01 /home/abuild/rpmbuild/BUILD/firefox-79.0/js/src/jsdate.cpp:1067:55: error: call to non-constexpr function ‘static std::size_t std::char_traits<char>::length(const char_type*)’
[ 192s] 1:43.01 min = std::min(min, std::char_traits<char>::length(keyword.chars));
[ 192s] 1:43.01 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~

---

I can't locate closed bug easily om bugzilla, but a bug was filed by
aceman for TB build using gcc/g++ earlier this year. The compilation
failed due to a few usages of constexpr in the source code. : I noticed
the issue myself but since gcc/g++ is not officially supported I did not
bother to report it, but aceman's issue and the patch was exactly what I
had locally.

You may want to check it out in bugzilla to figure out how to circumvent
it. Or try gcc-9 first.

Chiaki

[ISHIKAWA,chiaki]

I think it was *Bug 1652115
<https://bugzilla.mozilla.org/show_bug.cgi?id=1652115>
*

*However, given that I don't see the bug in M-C portion of the code (and
presumably aceman doesn't either), you may want to upgrade to gcc-9 (at
least gcc 9.3)

ishikawa@ip030:/home/ishikawa$ gcc --version
gcc (Debian 9.3.0-18) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Or you may have to tinker with the source code to unfold the constexpr
value yourself until gcc-7 is satisified. That may not be fun.

Chiaki


Th
*

[tcam...@mozilla.com]

The specific compiler error seems to be that "std::char_traits<char>::length" is not constexpr. It seems that your C++ standard library is not compatible with C++17 when the char_traits::length function was modified to be constexpr friendly.

Your logs show libstdc++ 7.1.1 being used, while support for constexpr char_traits requires version 8.1+. The OpenSUSE package list shows an "official update" supporting Leap 42.3 that should be recent enough: https://software.opensuse.org/package/libstdc++6 Are you able to use this updated libstdc++?