There are significant file size gains to be had by stripping the binaries before shipping them. This has been an issue for the Mozilla folks. We should keep the unstripped opt binaries also for support purposes. There is one gotcha - we need to re-run shlibsign on all the freebl DSOs and the softokn3, as well as all the other files that have a CHK file. So we need to keep two sets of CHK files as well. Only the stripped libraries with matching CHK files should be put into the JAR files we ship. This needs to be done for all Unix platforms. Nelson tells me it's already happening on Windows (automatic stripping OPT mode) so nothing to do there.

What are we giving up by stripping the binaries ? Why should we keep the unstripped opt binaries ? Who is going to use these unstripped opt binaries ?

(In reply to comment #1) > What are we giving up by stripping the binaries ? The ability to read core files > Why should we keep the unstripped opt binaries ? To be able to read core files > Who is going to use these unstripped opt binaries ? We are. IMO, mozilla should ship stripped binaries, if it wants to do so. I would not recommend that Sun do so.

Mozilla claims to already be shipping stripped binaries in https://bugzilla.mozilla.org/show_bug.cgi?id=389343#c42 . If that's really the case, then this bug should be a WONTFIX.

We already strip and regenerate the .chk files in packager.mk: http://mxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/packager.mk#338

Excellent!

This is WONTFIX rather than WORKSFORME since the standalone NSS build is still not stripping the optimized binaries. It only happens when building NSS as part of Mozilla client products, which is not the general case.