GNOME Bugzilla – Bug 356774
More NSS-related build problems
Last modified: 2013-09-10 13:42:18 UTC
This is a slightly different twist on bug #271045, bug #320405, and bug #335434. I tried compiling evolution-data-server from CVS HEAD on a Debian "Etch" system that happened to have the libnss3 and libnspr4 packages installed, but not the libnss3-dev or libnspr4-dev packages (containing the headers files). The configure script correctly detected that the *libraries* were present and enabled the HAVE_NSS preprocessor definition in config.h. Also, the HAVE_NSPR_H and HAVE_NSS_H definitions in config.h were disabled, which was correct for this case since the header files were not installed. However e-msgport.c failed to build because it uses HAVE_NSS (i.e. "is the library present?") for conditional compilation, as in: #ifdef HAVE_NSS #include <nspr.h> #endif It should instead use HAVE_NSPR_H (i.e. "is the header present?"), as in: #ifdef HAVE_NSPR_H #include <nspr.h> #endif Unfortunately the HAVE_NSPR_H and HAVE_NSS_H definitions remained disabled after installing the development packages and reconfiguring (from scratch, even). I also checked that the headers are where they're supposed to be: /usr/include/nspr/nspr.h /usr/include/nss/nss.h So there are two problems: 1) The HAVE_NSPR_H and HAVE_NSS_H definitions are not enabled when they should be. 2) Conditional compilation should be driven by the HAVE_NSPR_H and/or HAVE_NSS_H definitions, not HAVE_NSS. I'm trying to trace my way through all the autoconf-foo in configure.in. It looks like the relevant logic starts around line 400.
Another data point for problem (1): $ ./configure --with-nspr-includes=/usr/include/nspr \ --with-nss-includes=/usr/include/nss This correctly enables the HAVE_NSPR_H and HAVE_NSS_H definitions. But those options should not be necessary since the headers are in a standard location. And it still leaves problem (2) unsolved.
Another data point for problem (1): $ ./configure ... checking Mozilla NSPR pkg-config module name... xulrunner-nspr checking Mozilla NSS pkg-config module name... xulrunner-nss ... $ ./configure --with-nspr-includes=/usr/include/nspr \ --with-nss-includes=/usr/include/nss ... checking for Mozilla nspr4 includes in /usr/include/nspr... "" checking nspr.h usability... yes checking nspr.h presence... yes checking for nspr.h... yes ... checking for Mozilla nss3 includes in /usr/include/nss... "" checking nss.h usability... yes checking nss.h presence... yes checking for nss.h... yes ... Also, after staring at configure.in for awhile, it looks like the "x${check_manually}" = "xno" code path does not call AC_CHECK_HEADERS(nspr.h nss.h ...) which explains why HAVE_NSPR_H and HAVE_NSS_H are not defined in config.h.
Since I'm not an expert at this autoconf stuff, this may turn out to be NOTABUG. Waiting for confirmation before investigating this further.
Created attachment 73047 [details] [review] Proposed patch Patch to address problem (2), just to get it off my hands.
harish: *poke*
Please look at this patch someone.
Matthew : You are right about the conditional compilation being driven by HAVE_NSS instead of HAVE_NSS_H - this is clearly wrong. However, I am unclear about the first one - From the comments on camel.c:34 and the somewhat vague logic in configure.in, I suspect the code clearly wants to make a distinction between the system nss libraries/headers and the mozilla libraries and takes care not to include the former. I am not aware why this is so - it is possible that the reason why this had been done by the authors ceases to be true now Or if it is still valid, the rationale needs to be captured in the configure script as a comment. Without knowing more about this, I am referring this to the camel hackers for beter answers and re-assigning this to the right component. Thanks for your patience.
Also see bug 344790.
*** Bug 489223 has been marked as a duplicate of this bug. ***
We need to address this. Pending for a long time.
As I discussed it with Matt on IRC, it helped him to work so we can commit it to trunk. There was only one thing I noticed, in camel.c is included both nspr.h and nss.h, but only check for HAVE_NSS_H is there, so we should check for both of them, I guess. Feel free to fix it and commit to trunk. (Unfortunately most of the patch is "broken", because of white spaces clean up, I guess.)
From my original comment, part (1) is the more difficult problem here. If I'm recalling my own notes correctly, the problem boils down to this: Detecting NSS by running "configure" with no options should be the simplest case, but is in fact broken. It will use pkg-config to try to detect the presence of NSS and NSPR modules from either Firefox, Mozilla, or Seamonkey. This step is successful; it does indeed find the pkg-config modules. The problem is when pkg-config is used, the HAVE_NSPR_H and HAVE_NSS_H macros in the resulting "config.h" file remain disabled. Consequently, when coupled with the patch I've submitted for part (2), NSS support will NOT be compiled in. This is contrary to what the configuration summary will claim in this case. Here's a demonstration. For starters, my Fedora system configuration: /lib/libnss3.so /lib/libnspr4.so /usr/include/nss3/nss.h /usr/include/nspr4/nspr.h $ pkg-config --cflags nss nspr -I/usr/include/nss3 -I/usr/include/nspr4 $ pkg-config --libs nss nspr -L/lib -lssl3 -lsmime3 -lnss3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl Steps to Reproduce: 1) $ ./configure (no options) Configuration summary claims: SSL support: yes (Mozilla NSS) SMIME support: yes (Mozilla NSS) The "nss" and "nspr" pkg-config modules were found. 2) Resulting "config.h" mistakenly claims missing header files. NSS support, therefore, will NOT be compiled in. /* Define to 1 if you have the <nspr.h> header file. */ /* #undef HAVE_NSPR_H */ /* Define if you have NSS */ #define HAVE_NSS 1 /* Define to 1 if you have the <nss.h> header file. */ /* #undef HAVE_NSS_H */ Question for Srini: As an aside, how important is it that we continue to support static linking of the NSS and NSPR libraries? This seems to be the root cause of the massively complicated NSS configuration logic. Requiring the use of pkg-config modules for NSS support would go a long way towards cleaning up this mess. It would allows us to dump the --with-[nss|nspr]-[libs|includes] options. Does anyone still statically link NSS into evolution-data-server?
Matt, I really don't remember any case. But that shouldn't be the deciding thing. Lot of things could be decided on agreement before me/you came to Evolution. I would suggest you to post a email to e-h list and give a time for people to revert back. That way we say and do it. I hope all the people who care about that would be listening to it :)
Will do. In the meantime I'll check whether pkg-config offers any kind of support for static linking. That would be ideal.
*** Bug 353852 has been marked as a duplicate of this bug. ***
Just ran into a related possibly problem when trying to compile evolution-data-server from git master: I only had libnspr*-dev packages installed, but not libnss*-dev. ./autogen.sh ran fine and didn't complain, but the compilation failed in e-msgport.c with "e-msgport.c:39:18: error: nspr.h: No such file or directory". The problem seems to be that configure switches to "check_manually" when it doesn't find both nss and nspr pkg-config information. And then the build fails.
I will post a rewrite soon.
Created attachment 138396 [details] [review] EDS - NSS / NSPR rewrite v3
Created attachment 138398 [details] [review] EVO - NSS / NSPR rewrite v3 Both rewrite the way NSS / NSPR is detected. As I haven't worked with NSS / NSPR before, I would consider this stuff as experimental. I will add an version check if these patches do the trick, as it depends on NSS 3.1.1 and NSPR 4.6.1 The patch does the following : Replaced HAVE_NSS by HAVE_SSL (HAVE_SSL is a synonym for NSPR & NSS Flags) -> think this was a leftover from the time when OpenSSL was used Replaced --enable-nss by --enable-ssl as it is the only provider for SSL We check now in two different flavors : If pkg-config does the trick, set the flags through pkg-config --> everythings fine, continue and use the old tests to set the HAVE_* flags and to check for breakage through this patch If pkg-config fails or does not detect BOTH pkg-config files (nss AND nspr), autoconf checks for the nspr/nss-config programs and sets the flags then. If both fail, build fails. As nspr/nss-config should be always shipped since the mentioned versions, it should always work. The pkg-config files are prefered ( like in the comments I added ) as some distributions (misuse?) pkg-config files for dirty hacks. Please test carefully.
Created attachment 138462 [details] [review] EDS Updated patch fixes few header files left ( HAVE_NSS instead of HAVE_SSL )
Created attachment 138463 [details] [review] EVO Updated patch
Created attachment 138548 [details] [review] EDS - final patch This includes version checking. No more errors found and works for me.
Created attachment 138549 [details] [review] EVO - final patch Same as above.
Created attachment 138551 [details] [review] EDS - final patch take 2 Made an error with git. Sorry.
Created attachment 138553 [details] [review] EDS - final patch take 3 Don't know whery my head is...
Created attachment 138554 [details] [review] -.- Gnarf. This time the correct file...
I suppose Matt is on this, even I thought some rewrites of configure.ac had been done in the recent past already. Am I wrong?
Think this should be cleaned up. The patches I posted here should be removed as soon as possible as they are not correct anymore. Think the comments for the patches should be removed too, as they make the bug unreadable. I don't know what the status is currently, however, in current git I think these problems should be fixed. If not, please update!
Thanks, OK, I'm closing this per comment #28. Please reopen if I'm wrong.