Re: It seems that Firefox is now at 115.0.3esr now 115.1.0 stuck at libstdc++ version...

[chippy]

On Mon, 2023-08-21 at 13:09 +0200, chippy wrote:
> On Sun, 2023-07-30 at 16:17 -0400, Mark H Weaver wrote:
> > Hi,
> > 
> > chippy via help-gnuzilla <help-gnuzilla@gnu.org> writes:
> > 
> > > Hi everyone, I saw today that Firefox Esr is now at version
> > > 115.0.3esr,
> > 
> > Mozilla are currently supporting two ESR branches: 102 and 115.
> > According to their release calendar
> > <https://wiki.mozilla.org/Release_Management/Calendar>, they will
> > continue supporting version 102 until August 29.
> > 
> > History shows that IceCat tends not to be updated until upstream
> > support
> > has been dropped from the older ESR branch.  One rationale for this
> > practice is that it gives more time for undesirable behavior in the
> > newer Firefox version to be discovered and for mitigations to be
> > found.
> > 
> > > I also saw that there is no 'esr' in between 102.13.0esr and
> > > 115.0.1esr. What happened? Did Mozilla Foundation decided to skip
> > > some
> > > releases?
> > 
> > Yes, and that's how the ESR branches have always worked.  There
> > have
> > only been ESR branches for Firefox versions 115, 102, 91, 78, 68,
> > 60,
> > 52, 45, 38, 31, 24, 17 and 10, as shown in the "past releases"
> > section
> > of the Firefox release calendar that I linked above.
> > 
> > This approach is essentially the same as what the developers of
> > upstream
> > Linux (the kernel) do with their long-term support (LTS) releases:
> > not
> > every stable Linux release branch becomes an LTS branch.
> > 
> > > I tried to run makeicecat replacing the version numbers (and the
> > > checksum of course) but the patch "about-addons" unfortunately
> > > failed.
> > > I saw the file is sligthly changed, but it should be doable.
> > 
> > In practice, updating IceCat to a new ESR branch is a nontrivial
> > job.
> > You can look at the history of the Gnuzilla Git repository to see
> > the
> > kinds of changes that have been required in the past, but those
> > changes
> > are different for each new release, so one cannot simply use
> > history
> > as
> > a guide.
> > 
> > I also consider it important to test each major new IceCat release
> > with
> > a packet analyzer to detect any obvious attempts to "phone home" to
> > servers (e.g. at Mozilla or Google) that were not explicitly asked
> > for
> > by the web site that the user asked to visit.
> > 
> > Having said all of this, if you'd like to get started on the
> > process
> > of
> > updating IceCat to version 115, please feel free to work on it.
> > Especially if you are able to get the point of building a mostly
> > working
> > browser, even if it hasn't been fully tested or has some problems,
> > that
> > would be a very useful contribution!
> > 
> >      Thanks,
> >        Mark
> 
> Hi, I've been trying to build version 115.1.0esr using makeicecat,
> and
> if i remove 'some' patch files, apparently it goes through.
> 
> But when i try 'make' it breaks on one check:
> 
>  0:01.93 DEBUG: <truncated - see config.log for full output>
>  0:01.93 DEBUG: |                 #if defined(__GLIBCXX__) &&
> !defined(_GLIBCXX_RELEASE)
>  0:01.93 DEBUG: | #  error libstdc++ nott new enough
>  0:01.93 DEBUG: | #endif
>  0:01.93 DEBUG: | #if defined(_GLIBCXX_RELEASE)
>  0:01.93 DEBUG: | #  if _GLIBCXX_RELEASE < 8
>  0:01.93 DEBUG: | #    error libstdc++ nnot new enough
>  0:01.93 DEBUG: | #  else
>  0:01.93 DEBUG: |      (void) 0
>  0:01.93 DEBUG: | #  endif
>  0:01.93 DEBUG: | #endif
>  0:01.93 DEBUG: |                   ;
>  0:01.93 DEBUG: |                   return 0;
>  0:01.93 DEBUG: |                 }
>  0:01.93 DEBUG: Executing: `/usr/bin/clang++ --sysroot
> /home/g/.mozbuild/sysroot-x86_64-linux-gnu -std=gnu++17
> /tmp/conftest.f2dlu64k.cpp -c`
>  0:01.93 DEBUG: The command returned non-zero exit status 1.
>  0:01.93 DEBUG: Its error output was:
>  0:01.93 DEBUG: | /tmp/conftest.f2dlu64k.cpp:10:6: error: libstdc++
> nnot new enough
>  0:01.93 DEBUG: | #    error libstdc++ nnot new enough
>  0:01.93 DEBUG: |      ^
>  0:01.93 DEBUG: | 1 error generated.
>  0:01.94 ERROR: The libstdc++ in use is not new enough.  Please run
> ./mach bootstrap to update your compiler, or update your system
> libstdc++ installation.
> 
> I checked around and indeed a quick diff between toolchain.configure 
> in version 102.14.0esr and 115.1.0esr shows differences in minimum
> required version of clang, clang/llvm, libstdc++.
> 
> The breaking function returns the same error message for two
> different
> conditions, i could narrow it down to this (slightly changing the
> error
> message not->nnot): 
> 
> "#  if _GLIBCXX_RELEASE < %d" % minimum_gcc_version().major,
>             "#    error libstdc++ nnot new enough",
> 
> And indeed with the file coming from 102.14.0esr i see
> 
> def minimum_gcc_version():
>     return Version("7.1.0")
> 
> 
> while with the 115.1.0esr version i see:
> 
> def minimum_gcc_version():
>     return Version("8.1.0")
> 
> It's a bit confusing because on my machine i have:
> ✗ gcc --version
> gcc (Debian 13.2.0-2) 13.2.0
> 
> 
> I'm on Debian testing and as of now I'm stuck on trying to understand
> what to update (and how) in order to satisfy these requirements.
> 
> I've been looking for this problem on FF (release notes, bugzilla,
> ecc)
> but i couldn't find much. 
> 
> I also realistically expect this problem might very well be just a
> consequence of a different underlining problem
> 
> I'm not expert in compilers, so if someone wants to chime in with a
> tip
> or directions, would be awesome.
> 
> Meanwhile I'll try to understand the problem and find a solution.
> 
> Thank you 
> Chippy
>  
Hi again 

sorry if I keep hammering the ML but I was just able to move forward
and I just didn't want people to spend time on this.

I tried on debian unstable and it passed the configure checks on
libstdc++. 

I only had to comment out a line in
devtools/client/netmonitor/src/connector/moz.build (31) for an error in
./mach build, which i believe comes from the changes i made in
makeicecat,):

0:12.75 FATAL ERROR PROCESSING MOZBUILD FILE
 0:12.75 ==============================
 0:12.75 
 0:12.75 The error occurred while processing the following file:
 0:12.75 
 0:12.75     /tmp/gnuzilla/icecat-115.1.0/devtools/templates.mozbuild
 0:12.75 
 0:12.75 This file was included as part of processing:
 0:12.75 
 0:12.75     /tmp/gnuzilla/icecat-
115.1.0/devtools/client/netmonitor/src/connector/moz.build
 0:12.75 
 0:12.75 The error was triggered on line 31 of this file:
 0:12.75 
 0:12.75     base += [m for m in modules]
 0:12.75 
 0:12.75 An error was encountered as part of executing the file itself.
The error appears to be the fault of the script.
 0:12.75 
 0:12.75 The error as reported by Python is:
 0:12.75 
 0:12.75     ['mozbuild.util.UnsortedError: An attempt was made to add
an unsorted sequence to a list. The incoming list is unsorted starting
at element 0. We expected "har-metadata-collector.js" but got "icecat-
data-provider.js"\n']


besides that it went up belly up:

46:44.86 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:596:14: error: unknown
type name 'aContentPolicyType'; did you mean 'nsContentPolicyType'?
46:44.86              aContentPolicyType ==
ExtContentPolicy::TYPE_IMAGESET) {
46:44.86              ^~~~~~~~~~~~~~~~~~
46:44.86              nsContentPolicyType
46:44.86 /tmp/gnuzilla/icecat-115.1.0/obj-x86_64-pc-linux-
gnu/dist/include/nsIContentPolicy.h:139:48: note: 'nsContentPolicyType'
declared here
46:44.86 typedef nsIContentPolicy::nsContentPolicyType 
nsContentPolicyType;
46:44.86                                                ^
46:44.86 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:596:33: error: expected
')'
46:44.86              aContentPolicyType ==
ExtContentPolicy::TYPE_IMAGESET) {
46:44.87                                 ^
46:44.87 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:576:50: note: to match
this '('
46:44.87 nsresult nsHttpHandler::AddStandardRequestHeaders(
46:44.87                                                  ^
46:44.87 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:576:25: error: out-of-
line definition of 'AddStandardRequestHeaders' does not match any
declaration in 'mozilla::net::nsHttpHandler'
46:44.87 nsresult nsHttpHandler::AddStandardRequestHeaders(
46:44.87                         ^~~~~~~~~~~~~~~~~~~~~~~~~
46:44.87 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:597:11: error: member
reference base type 'int (int, struct sockaddr *__restrict, socklen_t
*__restrict)' (aka 'int (int, sockaddr *__restrict, unsigned int
*__restrict)') is not a structure or union
46:44.87     accept.Assign(mImageAcceptHeader);
46:44.87     ~~~~~~^~~~~~~
46:44.87 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:598:5: error: expected
unqualified-id
46:44.87   } else if (aContentPolicyType ==
ExtContentPolicy::TYPE_STYLESHEET) {
46:44.87     ^
46:44.88 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:600:5: error: expected
unqualified-id
46:44.88   } else {
46:44.88     ^
46:44.96 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:604:3: error: C++
requires a type specifier for all declarations
46:44.96   rv = request->SetHeader(nsHttp::Accept, accept, false,
46:44.96   ^
46:45.10 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:604:8: error: use of
undeclared identifier 'request'
46:45.10   rv = request->SetHeader(nsHttp::Accept, accept, false,
46:45.11        ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:606:3: error: expected
unqualified-id
46:45.11   if (NS_FAILED(rv)) return rv;
46:45.11   ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:610:3: error: expected
unqualified-id
46:45.11   if (mAcceptLanguagesIsDirty) {
46:45.11   ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:616:3: error: expected
unqualified-id
46:45.11   if (!mAcceptLanguages.IsEmpty()) {
46:45.11   ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:623:3: error: expected
unqualified-id
46:45.11   if (isSecure) {
46:45.11   ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:626:5: error: expected
unqualified-id
46:45.11   } else {
46:45.11     ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:630:3: error: expected
unqualified-id
46:45.11   if (NS_FAILED(rv)) return rv;
46:45.11   ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:633:3: error: expected
unqualified-id
46:45.11   if (mSafeHintEnabled || mParentalControlEnabled) {
46:45.11   ^
46:45.11 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:638:3: error: expected
unqualified-id
46:45.11   return NS_OK;
46:45.11   ^
46:45.28 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:641:10: error: use of
undeclared identifier 'nsHttpHandler'; did you mean
'mozilla::net::nsHttpHandler'?
46:45.28 nsresult nsHttpHandler::AddConnectionHeader(nsHttpRequestHead*
request,
46:45.28          ^~~~~~~~~~~~~
46:45.28          mozilla::net::nsHttpHandler
46:45.28 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/TRRServiceChannel.h:24:7: note:
'mozilla::net::nsHttpHandler' declared here
46:45.28 class nsHttpHandler;
46:45.28       ^
46:45.40 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:659:6: error: use of
undeclared identifier 'nsHttpHandler'; did you mean
'mozilla::net::nsHttpHandler'?
46:45.40 bool nsHttpHandler::IsAcceptableEncoding(const char* enc, bool
isSecure) {
46:45.41      ^~~~~~~~~~~~~
46:45.41      mozilla::net::nsHttpHandler
46:45.41 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/TRRServiceChannel.h:24:7: note:
'mozilla::net::nsHttpHandler' declared here
46:45.41 class nsHttpHandler;
46:45.41       ^
46:45.54 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/nsHttpHandler.cpp:685:25: error: use of
undeclared identifier 'nsHttpHandler'; did you mean
'mozilla::net::nsHttpHandler'?
46:45.54 nsISiteSecurityService* nsHttpHandler::GetSSService() {
46:45.54                         ^~~~~~~~~~~~~
46:45.54                         mozilla::net::nsHttpHandler
46:45.54 /tmp/gnuzilla/icecat-
115.1.0/netwerk/protocol/http/TRRServiceChannel.h:24:7: note:
'mozilla::net::nsHttpHandler' declared here
46:45.54 class nsHttpHandler;
46:45.54       ^
46:45.56 BUILDSTATUS BUILD_VERBOSE netwerk/sctp/datachannel
46:45.68 fatal error: too many errors emitted, stopping now [-ferror-
limit=]
46:45.70 20 errors generated.
46:45.78 gmake[4]: *** [/tmp/gnuzilla/icecat-
115.1.0/config/rules.mk:668: nsHttpHandler.o] Error 1
46:45.80 gmake[3]: *** [/tmp/gnuzilla/icecat-
115.1.0/config/recurse.mk:72: netwerk/protocol/http/target-objects]
Error 2
46:45.80 gmake[3]: *** Waiting for unfinished jobs....
47:25.15 gmake[4]: *** [/tmp/gnuzilla/icecat-
115.1.0/config/makefiles/rust.mk:441: force-cargo-library-build] Error
101
47:25.15 gmake[3]: *** [/tmp/gnuzilla/icecat-
115.1.0/config/recurse.mk:72: toolkit/library/rust/target] Error 2
47:26.23 gmake[2]: *** [/tmp/gnuzilla/icecat-
115.1.0/config/recurse.mk:34: compile] Error 2
47:26.25 gmake[1]: *** [/tmp/gnuzilla/icecat-
115.1.0/config/rules.mk:361: default] Error 2
47:26.28 gmake: *** [client.mk:60: build] Error 2
47:26.32 145 compiler warnings present.


Given the consistency of the errors on if and else, I suspect this also
is on me and the patches, missing patches and/or sed replacements. I
noticed that some of the patches had the right content but on more than
one line, the breaking ones were adjusted for the sake of finishing the
build, but others were not so I suspect this to be a result of my
doing.

I'll give another try being more careful on the consequences of the
changes.

Chippy