489029 - Enable NSS to be built with MOZCRT19 instead of MSVCR80 on Windows

Status: RESOLVED WONTFIX

(NSS :: Build, enhancement, P5)

Description

[Nelson Bolyard (seldom reads bugmail)]

Attachment: example of changes to build with MOZCRT19

Mozilla has its own version of the C Run Time library for Visual Studio 8.
In its builds of programs that use NSS, it builds them to use Mozilla's 
own C Run Time (named mozcrt19.dll) instead of with the normal C runtime.
It also builds them to NOT use a manifest, since they do not depend on 
the standard C Run Time library.  

It is not presently possible to take a nightly Mozilla Firefox or Thunderbird
build for Windows and substitute a developer's own NSS DLLs built with NSS's 
Makefiles  (as opposed to being build with Firefox's makefiles).  Instead it
is necessary to obtain Mozilla's MOZCRT19.DLL and its msvcrt.lib files, and 
use them in the NSS build.  It is also necessary to make small changes to 
some of NSS's and NSPR's Makefiles.  

This bug requests that those Makefiles be modified in such a way that it is 
possible to build NSS and NSPR with mozcrt19 without modifying coreconf and
nsprpub Makefiles.  

The attached patch shows unconditional changes to Makefiles to make them 
build with MOZCRT19.  These changes are obviously unsuitable for check in.
The next task is to make them conditional in some form.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

That patch is incomplete.  It produces a version of shlibsign.exe that will
not run, failing to find MSVCR80.DLL. :(

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Ignore comment 1.  I had rebuilt the tree without having the right 
environment variables set.  I just rebuilt it, again , with the right 
environment variables, and everything works fine.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I have built NSS and NSPR from the CVS trunk this way, and they build,
but all NSS programs built this way crash.  

The problem occurs when trunk NSPR calls LoadLibraryW.  We get a crash 
with a tombstone that tells us the program can't find MSVCR80.DLL.
I think that perhaps MOZCRT19 doesn't export that symbol.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

It's trying to load softokn3.dll.  I checked that all the NSS and NSPR DLLs
depend on MOZCRT19, and none depend on MSVCR80, so I don't know where the
reference to MSVCR80 comes from.  It happens in kernel32.dll.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

No, I was mistaken.  This is a build problem.  Some of the DLLs depend on 
MOZCRT19 and some don't.  Back to playing with make files. :(

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: improved (?) patch

This is not a candidate for checkin or even review.

Comment 7

[Wan-Teh Chang]

I'm not familiar with how Mozilla builds NSPR and NSS with
mozcrt19.dll.  I checked the CVS history and found that in
bug 418687 we added support for Mozilla to pass the necessary
linker flags to NSPR, and Ted wrote that patch.  So Ted is
the right person to ask.  Ben Smedberg is another good person
to ask.

Comment 8

[(not currently active) Ted Mielczarek]

Currently, we just set PATH

Comment 9

[(not currently active) Ted Mielczarek]

Currently, we just set PATH and LIB to include the path where we built our custom library, and the import library name is still msvcrt.lib, so it just takes the place of the default CRT lib. My patch in bug 487396 (which should land tomorrow) changes it so we make the import library name match the DLL name, and then pass
DLLFLAGS="-MANIFEST:NO -LIBPATH:\"$WIN32_CUSTOM_CRT_DIR\" -NODEFAULTLIB:msvcrt -NODEFAULTLIB:msvcrtd -DEFAULTLIB:mozcrt19"
where $WIN32_CUSTOM_CRT_DIR is the directory containing the compiled CRT+import library.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

yeah, using the name mozcrt19.lib instead of msvcrt.lib solves a big problem
that I ran into frequently.  I'd open a new shell window and forget to set
those environment variables, and do a build.  Instead of failing, it would
appear to succeed, but it would have used the standard CRT.  Now, with the
additional command line options to NOT use the standard libraries by their
usual names, the build fails if the needed files aren't in the PATH or LIB
path.  

Using the attachment above, I was able to build all of NSS with MOZCRT19
and am running my browser now with the NSS libraries I built.  So, I have 
achieved one of my objectives.  Now I just want to find a way to get this
into the Makefiles, so that I don't have to patch them in each of my 
workspaces.  That's really what this bug is about.

Comment 11

[(not currently active) Ted Mielczarek]

That patch has since landed. If you wanted tighter integration, you could support a variable like:
CRT_LIBRARY=mozcrt19

Which would then do something like:
ifdef CRT_LIBRARY
DLLFLAGS += -MANIFEST:NO -NODEFAULTLIB:msvcrt -NODEFAULTLIB:msvcrtd -DEFAULTLIB:$(CRT_LIBRARY)
endif

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.