#15079 closed enhancement (fixed)
Fix seamonkey build breakage from nss-3.65.
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | 11.0 |
| Component: | BOOK | Version: | git |
| Severity: | normal | Keywords: | |
| Cc: |
Description (last modified by )
AFAICS, for the next week no mozilla releases or betas will require nss-3.65 (after ff90 is in beta, that might change).
In the meantime, Jean-Marc on blfs-dev has confirmed the seamonkey build breakage and identified that reverting to nss-3.64 allowed seamonkey to build. I've now confirmed that, so I suggest we should temporarily revert to nss-3.64.
Edit: changed summary, based on upstream feedback.
Change History (13)
follow-up: 3 comment:1 by , 3 years ago
comment:2 by , 3 years ago
Bug raised against seamonkey build system (might be wrong component, or they might say it is an nss bug) https://bugzilla.mozilla.org/show_bug.cgi?id=1712625
comment:3 by , 3 years ago
Replying to Douglas R. Reno:
Can you try replacing CLEANUP with Cleanup? I'm looking at the version in ESR78 (https://hg.mozilla.org/releases/mozilla-esr78/file/tip/dom/indexedDB/IDBTransaction.h), and I see Cleanup instead of CLEANUP.
I looked at current firefox when I first hit this, and the file in seamonkey is very different (much older). I think Bruce is going to try using the shipped nss. Or perhaps upstream might make a comment.
comment:4 by , 3 years ago
I was able to build SM by disabling system nss. I think that is a better solution than reverting nss.
comment:5 by , 3 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
Upstream agrees, except maybe also disable system nspr. But if it works with system nspr then that should be good enough.
Seamonkey will only gain support for later nss and nspr versions after (firefox) ESR 91 appears, currently it is targeted at the versions in firefox-78esr (nss-3.53.1 and nspr-4.25 in ff78.10.1).
I assume the build will be bigger and slower. Will measure it when I get that far on my new build.
comment:6 by , 3 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | Downgrade nss to 3.64, as a temporary fix for seamonkey FTBFS. → Fix seamonkey build breakage from nss-3.65. |
comment:7 by , 3 years ago
I disagree with this solution. There are 25 packages in BLFS that use nss. One package failing is not enough to revert from the latest version, especially since there is a one line change to SM that allows it to build.
In addition, we are less than halfway through the release cycle. SM will be fixed well before we will make our next stable release.
comment:8 by , 3 years ago
I figured out another solution so that SM builds with nss-3.65. The problem is that nss includes '#define CLEANUP ...' in a public header. That is far too generic to be in such a header. In addition, it is only used internally by nss and it really should be in a private header.
Our solution should be to adjust the nss header:
sed -i 's/CLEANUP/NSS_&/' /usr/include/nss/pk11hpke.h
Or do the same thing to the header on the nss page in the book just before the install:
sed -i 's/CLEANUP/NSS_&/' public/nss/pk11hpke.h
cp -v -RL {public,private}/nss/* /usr/include/nss
but after the build. As an aside, why are we copying private nss headers? I checked Arch and they only copy the public headers. But that doesn't solve our problem; pk11hpke.h is a public header.
I have tested the sed above and SM builds fine with nss-3.65 (as modified).
comment:9 by , 3 years ago
I'd prefer to see more testing with the modified pk11pke.h header.
Meanwhile, exploring the time/space changes for using shipped nss.
On my optimized current system, where I reverted nss to 3.64, the build is marginally quicker with shipped nss, and 3MB bigger.
comment:10 by , 3 years ago
On my 10.1 systems, the install is 3MB bigger with total space increased by 0.1GB, but the reduced time here rounds to the same total of SBUs.
Now testing on my default gcc-11.1 system, the unusably slow one, to see how the figures look there.
Thee are all with only 4 cores online.
comment:11 by , 3 years ago
Well, on this dog-slow system (103m56.748s for client.mk with only 4 cores online, instead of the usual high-30minutes values, the space matches my optimized system (5.9G + 160M installed = 6.1G) and the SBU again rounds to 18. So, the measured values for largish packages are accurate enough. But keeping this open to see what happens on a default build on my i3 skylake (that is still in LFS).
comment:12 by , 3 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Skylake i3 build completed - in the past I've noticed that building mozilla packages on that box takes many more SBUs than on other machines - maybe SMT is the reason for that. In this case it again took more SBUs: 24 of them. I'll go with 18.
Fixed at @0194877132344df56bd74b0df0a2ce40e6fc4d78
Can you try replacing CLEANUP with Cleanup? I'm looking at the version in ESR78 (https://hg.mozilla.org/releases/mozilla-esr78/file/tip/dom/indexedDB/IDBTransaction.h), and I see Cleanup instead of CLEANUP.