353475 - Cannot run cmd tools compiled with VC++ 2005

Status: RESOLVED FIXED

(NSS :: Build, defect, P3)

Description

[Allan Beaufour]

I pulled the NSS tree, compiled it, and tried to run the cmd tools. All I got was:
"The application failed to initialize properly (0xc0000022). Click on
OK to terminate the application."
or (0xc0000142).

The fix was to export the .manifest files to the bin directory too. Windows is quite alien to me, but maybe the real solution is to compile the manifest files inside the binaries when using VC++ 2005?

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

I believe that, at present, none of the NSS developers is using VC++ 2005.
It seems like a step down from the older MSVC products that we're using.
One of us is going to have to bite the bullet, I guess.

Comment 2

[Allan Beaufour]

(In reply to comment #1)
> I believe that, at present, none of the NSS developers is using VC++ 2005.
> It seems like a step down from the older MSVC products that we're using.
> One of us is going to have to bite the bullet, I guess.

I hear lot of people complaining about it. It's not a hard fix. It's just a question of exporting the .manifest files too -- dunno what options to give to VC++ to get it to compile it in, but I can help since I'm stuck with that version :)

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Feel free to submit a patch

Comment 4

[Allan Beaufour]

Attachment: Manifest patch

This is just the patch from bug 249782. I've applied it to NSS 3.11.3, and it solves the problem for me.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 239634 [details] [diff] [review]
Manifest patch

I have several concerns about this patch.  It may be *close* to the right 
answer, but it needs a little adjustment first.

1) Main issue: ifdef MSMANIFEST_TOOL issues
MSMANIFEST is set to 1, even on Windows systems that don't have MSVC 2005.  
Perhaps it should be set conditionally based on the presence of the right 
version of msvc.  

2) manifest tool name conflicts
mt.exe already exists on my system.  If executed on my system, this would
run the MKS "mag tape" program (Yes, My windows system has a tape drive). 
So rather than hard-coding mt.exe into the makefile in numerous places,
a make variable should be used for that program name, so that it can be
overridden (perhaps with a full path name to that executable). 
Maybe the Makefile/script should try to construct a path name to mt.exe
that finds it where cl.exe lives (if that's the right place), to ensure
that it never runs the mag tape program.

3) silent operation undesirable  (lose the "@")
The make output log should show all the commands that happened.
It should not hide the execution of the commands that test for the 
presence of the manifest file and then run the manifest tool.

Comment 6

[Allan Beaufour]

(In reply to comment #5)
> (From update of attachment 239634 [details] [diff] [review] [edit])
> I have several concerns about this patch.  It may be *close* to the right 
> answer, but it needs a little adjustment first.
> 
> 1) Main issue: ifdef MSMANIFEST_TOOL issues
> MSMANIFEST is set to 1, even on Windows systems that don't have MSVC 2005.  
> Perhaps it should be set conditionally based on the presence of the right 
> version of msvc.  

Well, all three places check for the existence of a .manifest file, and only then run the mt.exe tool. Is it not a reasonable assumption that if it is there, it should be compiled in? The ifdef then only runs it on WIN32 systems.

> 2) manifest tool name conflicts
> mt.exe already exists on my system.  If executed on my system, this would
> run the MKS "mag tape" program (Yes, My windows system has a tape drive). 
> So rather than hard-coding mt.exe into the makefile in numerous places,
> a make variable should be used for that program name, so that it can be
> overridden (perhaps with a full path name to that executable).

Sure. Combined with the above, the same variable can be used.

> Maybe the Makefile/script should try to construct a path name to mt.exe
> that finds it where cl.exe lives (if that's the right place), to ensure
> that it never runs the mag tape program.

It's a fair point, but is this really a problem for the build system. If you have another tool called cl.exe in your path, is that not your problem?

The makefile could include a check, but then I'm really on foreign ground. Is there a Windows equivalent of 'dirname mt.exe', or is it the "perl way"?

> 3) silent operation undesirable  (lose the "@")
> The make output log should show all the commands that happened.
> It should not hide the execution of the commands that test for the 
> presence of the manifest file and then run the manifest tool.

Other places in rules.mk also uses silent mode, but it's the same to me :-)

Comment 7

[Allan Beaufour]

Attachment: Patch v2

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 240450 [details] [diff] [review]
Patch v2

r=nelson
Wan-Teh, do you concur?

Comment 9

[Allan Beaufour]

So, I wonder... where do this patch go? Just to trunk? Then I'll check it in.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Bug 353475. When building NSS with MSVC 2005, use the "mt" command to
embed the manifest files into the executables and DLLs.
Patch contributed by Allan Beaufour <[e-mail]>, r=nelson,wtchang

Checking in WIN32.mk; new revision: 1.22; previous revision: 1.21
Checking in rules.mk; new revision: 1.70; previous revision: 1.69

Will apply this patch to the NSS_3_11_BRANCH after it bakes on the trunk
for a bit (and Tinderbox is happy).

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Committed on NSS_3_11_BRANCH.
Checking in WIN32.mk; new revision: 1.20.2.2; previous revision: 1.20.2.1
Checking in rules.mk; new revision: 1.66.2.3; previous revision: 1.66.2.2