+++ This bug was initially created as a clone of Bug #1635110 +++

This is a tracking bug for Build and Release of SeaMonkey 2.53.4 beta(s).

Let's move here from https://bugzilla.mozilla.org/show_bug.cgi?id=1647129#c5

Under Linux, elfhack cannot optimize libxul.so when it compiled by clang+lld .

It could be fine to backport bug #1423822 up to its last commit https://hg.mozilla.org/releases/mozilla-esr68/rev/83e147e835386f3e46034b75ca769fa8d3e992aa

For the upcoming LTO world, is it possible now to pull configure stuff up to bug #1457482, or even better up to bug #1488587 ?

It allows start to try proper lto builds. IOW try to catch up with FF a bit for speed...

The patches have a bunch of prerequisites. LTO is not really a priority. It will not do much for performance, lenghten compile time and is error prone. We plan to align the build system with comm-central and 2.57 and switch to a mozilla top source dir. Needed for finally fixing rust compiles with Windows and also some other minor issues. I will keep the bugs in mind so that we can put them in later.

Minor crash fix taken from Waterfox classic. Might be needed for 2.57 later if we don't backport bug 288704

Version update for our mozilla-release branch

version update to 2.53.4 Beta 1 pre for our comm-release branch

version update to 2.53.4 Beta 1 for our comm-release branch

I fill bug #1657012 for elfhack.

A chain of commits can be applied cleanly enough, since elfhack is an isolated code.
(I guess the sum of 23 will not surprise anyone here. :) )

For bug #1657012:

Worry a bit about:
1484872-4 dac6d9ce5eecf27103122c663356df17b1b67cbe
(with a prerequisite 1163171-2 9f81a968a2584817c8e4738517c498050a2ec296, -idirafter --> -isystem )

At least missing "-fno-lto" in build/unix/elfhack/inject/moz.build may affect some downstreams nowadays which start to implement "always lto" policy (afaik Suse, Fedora tries now too), as well as unexpectable affect SM in some possible future...

sys/sysctl.h issue on Glibc >= 2.31
https://bugzilla.mozilla.org/show_bug.cgi?id=1631538#c4

bug #1413475, 5d39a3d4c19bb0aca97270788de5415ba5176311

taken care of for 2.53.4. Already in Bills build. Was just delayed because of 16.7 VS2019 issues:

At least missing "-fno-lto" in build/unix/elfhack/inject/moz.build may affect some downstreams nowadays which start to implement "always lto" policy
(afaik Suse, Fedora tries now too), as well as unexpectable affect SM in some possible future...

sys/sysctl.h issue on Glibc >= 2.31
Needs to wait. I would like to import earlier patches too first.

Windows mozconfigs and build scripts

Philosophical digression:

We apply several dozen commits for mozjemalloc.cpp, which add a couple of currently unneeded "moz_arena_*" functions etc. and increase the main "seamonkey" binary up to 4% and 9kb (I know it is small :) ), and all this is just to avoid a micro, but "not in order" patch https://bugzilla.mozilla.org/show_bug.cgi?id=1631538#c4 .

Certainly moz_arena stuff might become needed in the future. But in general, this way can lead to an increase in unnecessary code (and overall errors). Maybe for situations when the needed commits also add an unneeded (for the near future) functionality, but the patch is easy and small enough, just apply the patch (at the end of the ordinary commits' chain).

2.53.4b1 seems OK (CentOS-7, clang-9, rust-1.45)

Done and nothing serious came up