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

[chippy]

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