Opened 22 months ago

Closed 22 months ago

Last modified 20 months ago

#15079 closed enhancement (fixed)

Fix seamonkey build breakage from nss-3.65.

Reported by: ken@… Owned by: ken@…
Priority: normal Milestone: 11.0
Component: BOOK Version: git
Severity: normal Keywords:

Description (last modified by ken@…)

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)

comment:1 by Douglas R. Reno, 22 months ago

Can you try replacing CLEANUP with Cleanup? I'm looking at the version in ESR78 (, and I see Cleanup instead of CLEANUP.

comment:2 by ken@…, 22 months ago

Bug raised against seamonkey build system (might be wrong component, or they might say it is an nss bug)

in reply to:  1 comment:3 by ken@…, 22 months ago

Replying to Douglas R. Reno:

Can you try replacing CLEANUP with Cleanup? I'm looking at the version in ESR78 (, 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 Bruce Dubbs, 22 months ago

I was able to build SM by disabling system nss. I think that is a better solution than reverting nss.

comment:5 by ken@…, 22 months ago

Owner: changed from blfs-book to ken@…
Status: newassigned

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 ken@…, 22 months 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 Bruce Dubbs, 22 months 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 Bruce Dubbs, 22 months 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 ken@…, 22 months 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 ken@…, 22 months 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 ken@…, 22 months ago

Well, on this dog-slow system (103m56.748s for 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 ken@…, 22 months ago

Resolution: fixed
Status: assignedclosed

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

comment:13 by Bruce Dubbs, 20 months ago

Milestone: 10.211.0

Milestone renamed

Note: See TracTickets for help on using tickets.