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++? On Thursday, September 24, 2020 at 10:21:04 PM UTC-4, ISHIKAWA,chiaki wrote: > On 2020/09/25 11:07, ISHIKAWA,chiaki wrote: > > 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 > 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 > * _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
