844906 - Allow to override the library/libraries linked to sub libraries and tools

Status: NEW

(NSS :: Build, enhancement, P5)

Description

[Mike Hommey [:glandium]]

In a world where nss3, ssl3, smime3 and nssutil3 are all folded in a single library, possibly libxul, we need a way for the nss build system to allow an override for the libraries it links to softokn, nssckbi, etc.

Comment 1

[Ryan Sleevi]

Mike, this suggests a desire for a static build, but I believe that's not desired for NSS (in part, it breaks FIPS mode and system-wide NSS deployments). See bug #534471

Otherwise, I'm not sure what you mean by "folded in a single library"

Comment 2

[Mike Hommey [:glandium]]

(In reply to Ryan Sleevi from comment #1)
> Mike, this suggests a desire for a static build, but I believe that's not
> desired for NSS (in part, it breaks FIPS mode and system-wide NSS
> deployments). See bug #534471
> 
> Otherwise, I'm not sure what you mean by "folded in a single library"

See bug 648407 (and it works)

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Ryan Sleevi from comment #1)
> Mike, this suggests a desire for a static build, but I believe that's not
> desired for NSS (in part, it breaks FIPS mode and system-wide NSS
> deployments). See bug #534471
> 
> Otherwise, I'm not sure what you mean by "folded in a single library"

Not really a single library. Instead, fold everything except freebl and softoken into one library, and possibly later fold freebl and softoken together library. That would still preserve the FIPS-iness, right?

I think it is good to do this as the default configuration of NSS on non-Unix, non-Linux platforms. It should make applications that use NSS faster and smaller (because NSS will be smaller due to better inter-source-file optimization).

Comment 4

[Ryan Sleevi]

Ah, yes, absolutely for that. As long as softoken is still kept outside, you shouldn't have any issues with FIPS, and I agree, that'd lead to more flexibility in  other aspects of NSS (such as libssl or libpkix).

This should not negatively affect Red Hat deployments either, since the system expressions of trust-et-al are handled by system PKCS#11 modules.