636615 - nspr-config --libs/--cflags don't work on windows

Status: RESOLVED WONTFIX

(NSPR :: NSPR, defect)

Description

[Paul Biggar]

Spidermonkey is supposed to be built using --with-nspr-libs=`nspr-config --libs`
However, on windows, this produces flags which aren't suitable for the visual studio C compiler.

It produces:
  -LC:/path_to_libs -lnspr4 -lplc4 -lplds4

It needs something like:
  C:\path_to_libs\nspr4.lib C:\path_to_libs\plds4.lib C:\path_to_libsplc4.lib

Comment 1

[Wan-Teh Chang]

Paul: thank you for the bug report.  I believe nspr-config was
intended for Unix only.  Do people really use the <package>-config
scripts on Windows now?  Where do they install the <package>-config
scripts?  In C:\Windows\System32?

Comment 2

[Paul Biggar]

(In reply to comment #1)
> I believe nspr-config was
> intended for Unix only.  Do people really use the <package>-config
> scripts on Windows now?  Where do they install the <package>-config
> scripts?  In C:\Windows\System32?

Thinking about it now, this use case is really only for SpiderMonkey. I guess we'd use this change where:

- we use nspr-config (ie a unix-style build system)
- we use the Visual C++ compiler

So basically, this reduces it to something built within MozillaBuild (if it were in cygwin, it'd use gcc not Visual C++), but which does not have it's own copy of NSPR. So that's just SpiderMonkey.

And actually, we're probably going to fix that in the near future by using NSPR from the Mozilla tree (bug 

All in all, I think "fixing" this probably isn't helpful.

Comment 3

[Jim Blandy :jimb]

I'd like to make nspr-config work. Mozilla uses the configure script based build system on all platforms, including Windows.

Mozilla's SpiderMonkey JavaScript engine usually gets built in one of two ways:

- As part of the larger Mozilla source tree. Here, the top level configure script calls NSPR's configure script, and then SpiderMonkey's configure script. It takes care of passing the right NSPR-related options to the SpiderMonkey. There's no problem here.

- Separately from the larger Mozilla source tree. JavaScript engine developers often build SpiderMonkey this way. Here, NSPR is an external dependency of SpiderMonkey, and the developers need to pass the right options to SpiderMonkey's configure script to tell it which NSPR to use. Developers may well have several NSPR builds present --- perhaps patched versions, or cross-compiled builds --- so they must be able to tell SpiderMonkey which build they want.

So, on all platforms, including Windows, there needs to be a way for an NSPR build to tell a SpiderMonkey configure script what CFLAGS and LIBS SpiderMonkey should use to get at it. We could have separate mechanisms for this on Unix and on Windows, but since we're using the configure/make-based build system on both platforms, it seems simplest to make nspr-config work everywhere.

I have a Windows box on order from Mozilla; when it arrives, I can begin working on a patch for this.

Comment 4

[Jim Blandy :jimb]

WTC, do you mind if I assign this bug to myself?

Comment 5

[Wan-Teh Chang]

jimb: I reassigned this bug to you.  Where do you plan to install nspr-config
on Windows?  In the C:\Windows\System32 directory?

<package>-config files are not used on Windows, so you will need to define
a new convention.

Comment 6

[Jim Blandy :jimb]

(In reply to comment #5)
> jimb: I reassigned this bug to you.

Thank you.

> Where do you plan to install nspr-config
> on Windows?  In the C:\Windows\System32 directory?
> 
> <package>-config files are not used on Windows, so you will need to define
> a new convention.

We are using a configure/make-based build system for Firefox on Windows. <package>-config scripts are designed for other packages' configure scripts to run; <package>-config scripts are an aspect of configure/make-based build systems, not of Unix or Windows per se. It's just that configure/make is not usually used on Windows.

When NSPR is configured normally, where does 'make install' put the libraries? I would think the nspr-config script should go in the same place.

Comment 7

[Jim Blandy :jimb]

The case in which we really need nspr-config scripts is as follows:

Developers working on our JavaScript engine, SpiderMonkey, often build the engine separately from the rest of Firefox, using a stand-alone JavaScript shell for debugging and running tests. This is much less cumbersome than working with the whole browser, so when the task at hand doesn't depend on the browser enviroment, it is the preferred way to work.

At present, one can configure SpiderMonkey either with or without thread support. Thread support requires NSPR. However, we will be removing this configuration option soon, and making thread support always present. Thus, the shell will always require NSPR.

Unfortunately, doing stand-alone SpiderMonkey builds is difficult at the moment. Please see "NSPR on Windows" here:

https://developer.mozilla.org/en/SpiderMonkey_Build_Documentation

This is terrible. We need a way to make this work smoothly. If we make nspr-config return the proper flags on Windows, then one need only pass --with-system-nspr and --with-nspr-prefix, and things will work. I would like to simplify things further by having SpiderMonkey take a --with-nspr[=PATH] switch, much like other packages' configure scripts do.

Comment 8

[Jim Blandy :jimb]

In bug 625895, Paul and Wes argued for including NSPR in the tree; I argued against, and cited this bug as part of my alternative solution.

Now, the momentum behind producing a stand-alone JS distribution has stalled (perhaps, in part, because of that disagreement about the general approach! I really regret having contributed stop-energy to the process, if that is what happened).

I am not actively working on this, so I'm unassigning myself from it.

Comment 9

[Wan-Teh Chang]

Jim: thank you for the status update.  Marked the bug WONTFIX.