255408 - Need to be able to build mozilla --with-system-nss

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Currently, there is no way to build Mozilla with a system NSS.  This really
needs to be fixed.  I hope someone on the cc list from the crypto team can help
out here.  This would be a big win for NSS I think, as it would let more people
use the RTM versions (which is what the NSS team wants AIUI).  I think Red Hat
would be willing to use RTM versions of NSS if this were fixed.

Comment 1

[Julien Pierre]

Christopher,

The mozilla browser generally uses the latest features of the latest version of
NSS. APIs get added to NSS minor releases all the time. If you try to build
Mozilla with a version of NSS in the OS, which is most likely older, some APIs
may be missing, and therefore your build will fail. In order to support your
proposal, you would need to create some sort of version management scheme to
make sure at the minimum that all the dependencies are satisfied. Sometimes
there are also specific bug fixes in NSS that get made for certain versions of
the browser so that if you use an older NSS, you may not get the expected
behavior, even if you manage to build against it.

Also note that we rely on Mozilla QA bug reports in large part to test our NSS
releases. Mozilla users are our guinea pigs. If people start running the latest
Mozilla betas without also running the latest NSS beta code, then it's likely
that NSS regressions will be found later, and that will decrease the quality oof
NSS releases.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #1)
> The mozilla browser generally uses the latest features of the latest version of
> NSS. APIs get added to NSS minor releases all the time. If you try to build
> Mozilla with a version of NSS in the OS, which is most likely older, some APIs
> may be missing, and therefore your build will fail. In order to support your
> proposal, you would need to create some sort of version management scheme to
> make sure at the minimum that all the dependencies are satisfied.

Julien, it is very trivial to require a specific version of a library in
building.  We do that for all our other system libraries as well.  Grep
configure.in for PNG, JPEG, etc.  We (Red Hat/Fedora) intend to always ship the
latest NSS release version anyway (at the time of release).

> Sometimes
> there are also specific bug fixes in NSS that get made for certain versions of
> the browser so that if you use an older NSS, you may not get the expected
> behavior, even if you manage to build against it.

And we can easily add that patch to our source tree, and build it as well.

> Also note that we rely on Mozilla QA bug reports in large part to test our NSS
> releases. Mozilla users are our guinea pigs. If people start running the latest
> Mozilla betas without also running the latest NSS beta code, then it's likely
> that NSS regressions will be found later, and that will decrease the quality oof
> NSS releases.

We don't ship beta releases, only final versions of software.  There should be
no impact here.  Don't forget that most of the users that install Mozilla get
binaries.  Only a very small handful build their own.  Many of those are actual
Mozilla developers.  I doubt many of them really would turn this on.

I am requesting this compile flag because it has very real benefits for vendors.
 For example:

- Every time Mozilla upgrades happen, software which relies on NSS will break
because of a different NSS location (/usr/lib/mozilla-1.6 vs.
/usr/lib/mozilla-1.7).  And yes the location must be different for each version
because it is possible to have multiple versions installed.

- If there are critical NSS bug fixes (for e.g. major security flaws), we can
build a new NSS instead of having to rebuild all of Mozilla, then all of every
application that depends on NSS.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I completely agree with this request for enhancement (RFE) to the mozilla 
browser's build system (and for bird and fox too).  

We (NSS team) were releasing numbered binary releases of NSS long before 
NSS was added to the mozilla open source repository, and we always wished 
that mozilla would use out binary releases, (built from open source), 
rather than building its own releases from its own source tags (as it does).  
The NSS team has always taken the stance that we only support our own 
releases, and not other builds made by other groups from other source 
combinations (i.e. other tags than our RTM tags).

As I understand this bug/RFE, Chris observes that mozilla CANNOT even
be built with released NSS headers and shared libs, and he wishes that
it could be.  I don't see how or why any members of the NSS team should
oppose that!  

But it should be clear that the change requested here is to the build 
system of mozilla, not a change to NSS or its build system.  It seems
unlikely to me that any of the paid members of the NSS team would find
such work among his job responsibilities.  

Comment 4

[Julien Pierre]

Christopher,

I am curious what other software you have that depends on NSS . The reason I ask
is because Sun ships binary versions of NSS in a shared location, so in a sense
we already do this in Solaris and in our Java Enterprise Server software, which,
incidently, also runs on Linux (though I think our NSS shared location for Linux
is different). So we have a lot of experience doing this, just not with the
Mozilla browser

It's reasonable to make the build system work with binary releases / headers, as
long as you are able to manage the dependencies. Patching your mozilla tree is
not a very clean way, though.

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #4)
> I am curious what other software you have that depends on NSS .

Gaim, Evolution, and of course, Mozilla and all things which depend on it.

Comment 6

[Christopher Blizzard (:blizzard)]

And the Directory Server is not far behind.  Would be good if we could get .pc
files included in nss as well.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Is this bug filed against the correct product?
Seems to me this applies to all mozilla client products, 
not just seamonkey.
Is this a PSM bug?
a "core" bug?
In any case, I'm sure it's not an NSS bug. 
It has to do with building things other than NSS.

Comment 8

[Wolfgang Rosenauer [:wolfiR]]

indeed this is a CORE -> Build Config feature request IMHO.
Chris, are you working on it actually?

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

I'm the assignee, but not currently working on it.  Helpwanted if anyone wants
to take a stab.

Comment 10

[Wan-Teh Chang]

Kai, could you take a stab at this?

cls, we may need your help to implement --with-system-nss.

Comment 11

[Kai Engert (:KaiE:)]

At the very moment I'm trying to set up a nss.spec file, in order to build system NSS RPM, as a preparation to work on this bug. If you already have one, please let me know.

Comment 12

[Wan-Teh Chang]

Kai, we already have an nss.spec file at Red Hat.
Unfortunately I only have it at work, so you need
to wait until next Monday.  Meantime, you may be
able to start with the spec file in
mozilla/security/nss/pkg/linux, which Sun uses to
build their NSS RPMs (used only by Sun's NSS-based
servers).

Comment 13

[Kai Engert (:KaiE:)]

Attachment: Patch v1 - (run autoconf-2.13 after applying)

This patch makes it work for me.

I have used caillon's nspr.spec file, and I have written a rudimentary nss.spec file myself.

With no mozilla rpms installed on my system, but the nspr and nss rpms installed, Mozilla builds fine with this patch.

Missing points:
- I hardcoded the include directory /usr/include/nss because I do not know how to find that directory dynamically inside configure
- I have only tested on Linux. While this patch might not support system-nss on other platforms, I believe this patch will not break other platforms when not using the option

In addition, there was a code change required.
Library nssckbi is not linked in, but is loaded dynamically at runtime. As of today, PSM only searches inside the Mozilla distribution directory, and the GRE directory.

I have added an attempt to load nssckbi without specifying a directory, which hopefully will find the system-wide installed library. It behaved that way on my system and CA certificates got loaded successfully. I added this library search with lowest priority, so a library shipped with Mozilla will still override the system library.

I do not know if I have implemented the 3rd attempt correctly for the Mac platform.

Comment 14

[Wan-Teh Chang]

Kai,

You need to provide an 'nss-config' shell script, which
you invoke to find out about the NSS include directory
pathname and NSS library directory pathname.  See how
mozilla/configure.in invokes 'nspr-config' as an example.
Your --with-system-nss code should be very similar to
the --with-system-nspr code in mozilla/configure.in.

Comment 15

[Kai Engert (:KaiE:)]

Future versions of NSS will include a nss-config script.
For my testing I have already produced the appropriate script.

FYI, see http://kuix.de/misc/nspr-nss-rpm/20051207/

I'll be attaching (mostly identical) patches for Mozilla trunk, 1.8 branch and 1.7 branch.

When reviewing the added nss.m4 file, please note that is an almost identical copy of existing file nspr.m4, it has NSPR/nspr replaced by NSS/nss, version number adjusted, and NATIVE_NSS_INCLUDE_DIR added. As we are already using varilable NSS_LIBS in the build system, to minimize changes, I've chosen to prefix the global variables with NATIVE_ .

I have tested shared and static builds on Linux, Seamonkey, Firefox and Thunderbird.

Comment 16

[Kai Engert (:KaiE:)]

Attachment: Patch v2 trunk version (run autoconf-2.13)

Comment 17

[Kai Engert (:KaiE:)]

Attachment: Patch v2 branch 1.8 version (run autoconf-2.13)

Comment 18

[Kai Engert (:KaiE:)]

Attachment: Patch v2 branch 1.7 version (run autoconf-2.13)

Comment 19

[Kai Engert (:KaiE:)]

Attachment: Patch v2 / C++ only portion / ignores whitespace

Comment 20

[Kai Engert (:KaiE:)]

Comment on attachment 205723 [details] [diff] [review]
Patch v2 trunk version (run autoconf-2.13)

Can you please review? Please ignore the C++ change, will get reviewed separately.

Comment 21

[Kai Engert (:KaiE:)]

Comment on attachment 205726 [details] [diff] [review]
Patch v2 / C++ only portion / ignores whitespace

Can you please review the new logic to find the ckbi dynamic library?

Comment 22

[cls]

Comment on attachment 205723 [details] [diff] [review]
Patch v2 trunk version (run autoconf-2.13)

There's just a bunch of nits:

+MOZ_ARG_WITH_BOOL(system-nss,
+[  --with-system-nss      Use system installed NSS],
+    _USE_SYSTEM_NSS=1 )

This only handles the --with-system-nss case.  We need the additional argument to the macro so that --without-system-nss is handled as well.

+AC_SUBST(NATIVE_NSS_CFLAGS)
+AC_SUBST(NATIVE_NSS_INCLUDEDIR)
+AC_SUBST(NATIVE_NSS_LIBS)

Those AC_SUBSTs should be necessary since you already call them in nss.m4. 

I would drop NATIVE_ from  those variables and move the NSS_CFLAGS setting from config.mk to autoconf.mk.in .

Why doesn't NATIVE_NSS_LIBS include -lcrmf by default?

If we don't need to link against softokn3, then the reference should be removed.

+ifdef MOZ_NATIVE_NSS
+LOCAL_INCLUDES += -I$(NATIVE_NSS_INCLUDEDIR) \
+                  $(NULL)

Just use NSS_CFLAGS here.

Comment 23

[Kai Engert (:KaiE:)]

Chris, thanks for your review, however:


> +MOZ_ARG_WITH_BOOL(system-nss,
> +[  --with-system-nss      Use system installed NSS],
> +    _USE_SYSTEM_NSS=1 )
>
> This only handles the --with-system-nss case.  We need the additional argument
> to the macro so that --without-system-nss is handled as well.

But I think this works already?

- I duplicated the existing system-nspr code.
- The created configure script has a comment saying:
  "# Check whether --with-system-nss or --without-system-nss was given."
- I tried calling configure --without-system-nss --without-system-nspr and it works


> +AC_SUBST(NATIVE_NSS_CFLAGS)
> +AC_SUBST(NATIVE_NSS_INCLUDEDIR)
> +AC_SUBST(NATIVE_NSS_LIBS)
>
> Those AC_SUBSTs should be necessary since you already call them in nss.m4. 

I can remove them, but FYI, AC_SUBST(NSPR_CFLAGS) and AC_SUBST(NSPR_LIBS) are contained in both configure.in and nspr.m4
Do you want me to remove the existing duplicate entries for NSPR, too?


> Why doesn't NATIVE_NSS_LIBS include -lcrmf by default?

I don't understand why, but Wan-Teh requested lib crmf should NOT be included in nss-config's output, but applications should request to link with that library explicitly.


> I would drop NATIVE_ from  those variables 

Now this is complicated.

Renaming as you suggest would cause a naming collision.
We already use NSS_LIBS at many places in the build system.

Currently in the Mozilla build system, in config/config.mk, NSS_LIBS is manually set to the list of required nss libraries, which specifies additional libraries to nss-config's output.

I thought the NATIVE_ variable chould be the direct output of nss-config, and we continue to use variable NSS_LIBS for the list of libs chosen by the Mozilla application. That way existing dependent build systems (embedding apps) can continue to use variable NSS_LIBS.

If you insist on using NSS_LIBS only, should I try to += the additional libraries in config.mk?


> and move the NSS_CFLAGS setting from config.mk to autoconf.mk.in .

Sorry, I don't understand.
config.mk does not contain NSS_CLFAGS.
Please elaborate.


> If we don't need to link against softokn3, then the reference should be
> removed.

I don't understand. Who said we don't need to?


> +ifdef MOZ_NATIVE_NSS
> +LOCAL_INCLUDES += -I$(NATIVE_NSS_INCLUDEDIR) \
> +                  $(NULL)
> 
> Just use NSS_CFLAGS here.

Ok, I will remove the INCLUDEDIR variable and use CFLAGS.

Comment 24

[cls]

> - I duplicated the existing system-nspr code.
> - The created configure script has a comment saying:
>   "# Check whether --with-system-nss or --without-system-nss was given."
> - I tried calling configure --without-system-nss --without-system-nspr and it
> works

--without is the current default so putting it by itself will do nothing different.  To verify that the --without case works, you'd have to put both: --with-system-nss --without-system-nss  and then verify that MOZ_NATIVE_NSS is not set.  

But it does look like the NSPR case works. It doesn't look like it should.  MOZ_ARG_WITH_BOOL appears to behave differently than MOZ_ARG_ENABLE_BOOL.  My mistake.

> > +AC_SUBST(NATIVE_NSS_CFLAGS)
> > +AC_SUBST(NATIVE_NSS_INCLUDEDIR)
> > +AC_SUBST(NATIVE_NSS_LIBS)
> >
> > Those AC_SUBSTs should be necessary since you already call them in nss.m4. 
> 
> I can remove them, but FYI, AC_SUBST(NSPR_CFLAGS) and AC_SUBST(NSPR_LIBS) are
> contained in both configure.in and nspr.m4
> Do you want me to remove the existing duplicate entries for NSPR, too?

We subst NSPR_CFLAGS & NSPR_LIBS because we modify them in configure.in after AM_PATH_NSPR is called.  Since we don't do any additional modification of the nss-config output (yet), we don't need the additional substs.

> > I would drop NATIVE_ from  those variables 
> 
> Now this is complicated.
> 
> Renaming as you suggest would cause a naming collision.
> We already use NSS_LIBS at many places in the build system.
> 
> Currently in the Mozilla build system, in config/config.mk, NSS_LIBS is
> manually set to the list of required nss libraries, which specifies additional
> libraries to nss-config's output.
> 
> I thought the NATIVE_ variable chould be the direct output of nss-config, and
> we continue to use variable NSS_LIBS for the list of libs chosen by the Mozilla
> application. That way existing dependent build systems (embedding apps) can
> continue to use variable NSS_LIBS.
> 
> If you insist on using NSS_LIBS only, should I try to += the additional
> libraries in config.mk?

Is there any reason to make the pristine nss-config output available if it's not useable by the mozilla apps?

There shouldn't be a conflict as we should only be using one set of variables (NSS_CFLAGS & NSS_LIBS) to handle building against NSS regardless of whether it's the in-tree or system version.  Like the NSPR case, we should let configure.in handle any nss-config post-processing to put the variables into the correct format.

> > and move the NSS_CFLAGS setting from config.mk to autoconf.mk.in .
> 
> Sorry, I don't understand.
> config.mk does not contain NSS_CLFAGS.
> Please elaborate.

Sorry, I meant NSS_LIBS.  In general, I would want the NSS system variables to behave like the rest of the system variables.

> > If we don't need to link against softokn3, then the reference should be
> > removed.
> 
> I don't understand. Who said we don't need to?

Wan-Teh in bug 317620 comment 3.

Comment 25

[Kai Engert (:KaiE:)]

Attachment: Patch v3 (branch 1.8 version) (run autoconf-2.13)

C++ portion is unchanged.


> To verify that the --without case works, you'd have to put both:
> --with-system-nss --without-system-nss  and then verify that MOZ_NATIVE_NSS is
> not set.  

Verified


> > +AC_SUBST(NATIVE_NSS_CFLAGS)
> > +AC_SUBST(NATIVE_NSS_INCLUDEDIR)
> > +AC_SUBST(NATIVE_NSS_LIBS)
> >
> > Those AC_SUBSTs should be necessary since you already call them in nss.m4. 

I tried to remove them from configure.in

But that resulted in an error during compilation.
The string @NSS_CFLAGS@ was used on the command line.
I have added it back to configure.in and now it works.


> +ifdef MOZ_NATIVE_NSS
> +LOCAL_INCLUDES += -I$(NATIVE_NSS_INCLUDEDIR) \
> +                  $(NULL)
> 
> Just use NSS_CFLAGS here.

removed the INCLUDEDIR variable and now using CFLAGS.


> and move the NSS_LIBS setting from config.mk to autoconf.mk.in .
> I would want the NSS system variables to
> behave like the rest of the system variables.

Moved NSS_LIBS and NSS_DEP_LIBS


> > If we don't need to link against softokn3, then the reference should be
> > removed.

Removed references in directories build and config.
Did not yet remove the references that might be elsewhere in the build system.


> > > I would drop NATIVE_ from  those variables 
> > 
> > Now this is complicated.
> > 
> > Renaming as you suggest would cause a naming collision.
> > We already use NSS_LIBS at many places in the build system.
> > 
> > Currently in the Mozilla build system, in config/config.mk, NSS_LIBS is
> > manually set to the list of required nss libraries, which specifies additional
> > libraries to nss-config's output.
> > 
> > I thought the NATIVE_ variable chould be the direct output of nss-config, and
> > we continue to use variable NSS_LIBS for the list of libs chosen by the Mozilla
> > application. That way existing dependent build systems (embedding apps) can
> > continue to use variable NSS_LIBS.
> > 
> > If you insist on using NSS_LIBS only, should I try to += the additional
> > libraries in config.mk?
> 
> Is there any reason to make the pristine nss-config output available if it's
> not useable by the mozilla apps?

It's useful, because it points us to the library directory and also gives us
-Wl,-rpath-link,/usr/lib64

We just need to add the crmf library, as Wan-Teh prefers to not have that
library in nss-config's output.


> There shouldn't be a conflict as we should only be using one set of variables
> (NSS_CFLAGS & NSS_LIBS) to handle building against NSS regardless of whether
> it's the in-tree or system version.  Like the NSPR case, we should let
> configure.in handle any nss-config post-processing to put the variables into
> the correct format.

As you have suggested, I moved NSS_LIBS over to autoconf.mk.in
I have added the MOZ_NATIVE_NSS dependent postprocessing there.

Comment 26

[Kai Engert (:KaiE:)]

> But that resulted in an error during compilation.
> The string @NSS_CFLAGS@ was used on the command line.
> I have added it back to configure.in and now it works.

Please ignore that.

Comment 27

[Robert Relyea]

Kaie is correct, crmf should not be linked by default, only by those apps that need it. (mozilla is one of the few that actually needs crmf).

bob

Comment 28

[Wan-Teh Chang]

Comment on attachment 205726 [details] [diff] [review]
Patch v2 / C++ only portion / ignores whitespace

Kai,

Thanks for the patch.  It is basically correct. However,
I'd like to suggest some changes to make it more "idiomatic"
C++.

1. Please revert to the possible_ckbi_locations array.
Just add a third array element of 0.  The new switch
statement looks a little strange.

2. The XP_MAC case below is incorrect:

>+      if (!location)
>+      {
>+#ifdef XP_MAC
>+        fullModuleName = PR_GetLibraryName(nsnull, LOADABLE_CERTS_MODULE.get());
>+#else
>+        fullModuleName = PR_GetLibraryName(nsnull, "nssckbi");
>+#endif
>+      }

The XP_MAC case should be just
          fullModuleName = LOADABLE_CERTS_MODULE.get();
because LOADABLE_CERTS_MODULE is already the library
name (with the .shlb suffix).

Since XP_MAC is dead, I suggest that you not add the
XP_MAC case at all.

3. In the original code (not modified by this patch), we
have:

#ifndef XP_MAC
      PR_Free(fullModuleName); // allocated by NSPR
#endif

It is more correct to use PR_FreeLibraryName instead of
PR_Free to free the return value of PR_GetLibraryName.

Comment 29

[Wan-Teh Chang]

Comment on attachment 205791 [details] [diff] [review]
Patch v3 (branch 1.8 version) (run autoconf-2.13)

Kai,

Although I suggested that you remove -lsoftokn3 from
the linker flags, it needs to be replaced with
-Wl,-rpath-link,... on platforms that use GNU ld
(Linux, FreeBSD, etc.), and with -dylib_file ... on
Mac OS X.  See
http://lxr.mozilla.org/security/source/security/nss/cmd/platlibs.mk
as an example of how to do the right thing.

I know doing the right thing is a lot of work, so
I give you my blessing to continue to link with
-lsoftokn3, especially in the --without-system-nss
case.  In the --with-system-nss case, we can add
-Wl,-rpath-link,... to the nss-config and mozilla-nss.pc
files.  Also, system nss is usually installed in a
standard directory like /usr/lib, which makes the
-Wl,-rpath-link,... flag unnecessary.

Comment 30

[Benjamin Smedberg]

Comment on attachment 205791 [details] [diff] [review]
Patch v3 (branch 1.8 version) (run autoconf-2.13)

You can use the MOZ_FIX_LINK_PATHS macro to get the correct -rpath-link or -executable_path link flags if you wish (we'll need to fixup autoconf.mk.in to set it unconditionally, and upgrade a few of the oldest mac tboxen, but that's already the plan).

Comment 31

[Kai Engert (:KaiE:)]

Because the remove of -lsoftokn3 is optional, and we have some time pressure to get --with-system-nss working, I'd like to do the removal in a separate bug. I have just opened bug 320335.

Comment 32

[Kai Engert (:KaiE:)]

Attachment: Patch v4 / C++ only portion / ignores whitespace

Here is the new C++ patch after addressing Wan-Teh's comments.
As suggested I have removed the nssckbi handling for XP_MAC completely.

Comment 33

[Kai Engert (:KaiE:)]

Attachment: Patch v4 (branch 1.8 version) (run autoconf-2.13)

Chris, can you please review the build system changes?

This patch no longer removes softokn3, it just moves the link code to autoconf.mk.in as you had suggested.

Comment 34

[Kai Engert (:KaiE:)]

> I know doing the right thing is a lot of work, so
> I give you my blessing to continue to link with
> -lsoftokn3, especially in the --without-system-nss
> case.  

Thanks, the latest patch does not yet change that, change postponed to bug 320335


> In the --with-system-nss case, we can add
> -Wl,-rpath-link,... to the nss-config and mozilla-nss.pc
> files.  Also, system nss is usually installed in a
> standard directory like /usr/lib, which makes the
> -Wl,-rpath-link,... flag unnecessary.

The nss-config we have already produced (but not yet checked in to NSS), already contains the -Wl,-rpath-link, flag.

Comment 35

[Kai Engert (:KaiE:)]

Attachment: Patch v4 (branch 1.7 version) (run autoconf-2.13)

Comment 36

[Kai Engert (:KaiE:)]

Attachment: Patch v4 (trunk version) (run autoconf-2.13)

Comment 37

[Wan-Teh Chang]

Comment on attachment 205925 [details] [diff] [review]
Patch v4 / C++ only portion / ignores whitespace

r=wtc.

It would be nice to add a comment to explain what the
new 0 array entry means:

>     const char *possible_ckbi_locations[] = {
>       NS_GRE_DIR,
>-      NS_XPCOM_CURRENT_PROCESS_DIR
>+      NS_XPCOM_CURRENT_PROCESS_DIR,
>+      0
>     };

It doesn't mean "end of array".  Instead, it means
"search for ckbi in the directories on the shared
library/DLL search path".

Comment 38

[cls]

Attachment: Patch v5 (trunk)

Here's an updated version of kaie's patch that moves all of the platform logic into configure.in to mimic the system-nspr setup.

Comment 39

[Kai Engert (:KaiE:)]

FYI, just in case you did this accidentially, in security/manager/ssl/src/Makefile.in you also changed LOCAL_INCLUDES from its current "+=" to "=".

Comment 40

[Kai Engert (:KaiE:)]

Attachment: Patch v6 (trunk)

This patch is v5 + the comment requested by Wan-Teh

I'll check it in now.

Comment 41

[Kai Engert (:KaiE:)]

Checked in to trunk, marking fixed.

Comment 42

[Kai Engert (:KaiE:)]

Attachment: Patch v7 (landed on trunk, needs autoconf)

This is the patch as I had checked it in to the trunk, this new version includes fixes for two build failures. I verified this patch applies to the 1.8 branch.

I would like to request 1.8 branch checkin approval.
The patch adds a build system feature that is used on some Unix platforms, and having it on the 1.8 branch will simplify the build processes for releases off that branch.

Comment 43

[Kai Engert (:KaiE:)]

Checked in to 1.8 branch.

Comment 44

[Mike Hommey [:glandium]]

(In reply to comment #27)
> Kaie is correct, crmf should not be linked by default, only by those apps that
> need it. (mozilla is one of the few that actually needs crmf).

Sorry to clutter this bug with my questions, but I have two to of them about this:
- Is crmf really used by mozilla ? http://lxr.mozilla.org/seamonkey/search?string=crmf doesn't seem to indicate so...
- Why isn't crmf a shared library ?

Comment 45

[Mike Hommey [:glandium]]

Found the answer to my first question: http://developer.mozilla.org/en/docs/JavaScript_crypto

Comment 46

[Mike Hommey [:glandium]]

And the answer for the second in bug #294542. You can forget me. Sorry.

Comment 47

[Mike Hommey [:glandium]]

> The nss-config we have already produced (but not yet checked in to NSS),
> already contains the -Wl,-rpath-link, flag.

More than a year passed, and I still can't see nss-config in NSS...