1543545 - Allow to build NSS as a static library

Status: RESOLVED FIXED

(NSS :: Build, enhancement, P2)

Description

[Edouard Oger [:eoger]]

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

On some platforms like iOS, loading a dynamic library incurs a performance overhead. It also drives the binary size up. Static linking might help this a little, even if the PKCS#11 interface will force certain symbols to be present even when they aren't used.

Static linking to the "top level" libraries as described here is likely what we'll want to use. We can explore whether or not to statically link freebl and softoken as well, though that might be best done in stages. There are some changes with --test/test_build that might be used to help here.

This would not be the default build configuration, but it should be enabled through a build flag.

Comment 1

[Martin Thomson [:mt:]]

There are a few things to consider when statically linking NSS:

1. Exporting static libraries is relatively simple. We add a flag to build.sh (--static say) and use that to set a new gyp variable (static_libs). Getting those .a/.lib files into the build output directory should be simple enough. I think that we can export static libraries in addition to the dynamic libraries by changing the default of 'standalone_static_library' to 1.

2. We then need to stop NSS from loading softoken dynamically. We currently use NSS_TEST_BUILD to override the normal dynamic linking there. That #define needs to be more clearly named and linked to the --static option.

I've done this sort of static linking for testing and debugging in neqo. I can confirm that it works fine.

Note: NSPR is dynamically linked by default as well. NSPR produces static libraries already, so that's not a problem, but all three NSPR libraries define a function called libVersionPoint. Unfortunately, NSS requires both. That probably needs another bug. It is probably sufficient to disable the NSPR "version protocol" and have all instances of plvrsion.o/.obj excluded from the .a/.lib files.

Comment 2

[Martin Thomson [:mt:]]

Attachment: Bug 1543545 - Option to produce static libraries, r?

The fine folks in application services would like to use NSS, but would greatly
prefer static linking. Part of that is driven by iOS constraints on performance
and a possible rejection from the store for dynamic linking (NSS dynamically
loads softoken). This provides a build option that produces a fully statically
linked set of libraries.

Comment 3

[Martin Thomson [:mt:]]

https://hg.mozilla.org/projects/nss/rev/8a4cad364cf3eadda09035beb73d9d21c1b61b86

Comment 4

[Martin Thomson [:mt:]]

This creates the option to statically link softoken and it adds the .a/.lib files to the build output. It turned out to require a straight repurposing of the test_build flag. There was one piece left over, that I've opened Bug 1548179 for investigating whether that can be removed.