Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Cannot run cmd tools compiled with VC++ 2005

RESOLVED FIXED in 3.11.4

Status

NSS
Build
P3
normal
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: Allan Beaufour, Assigned: Allan Beaufour)

Tracking

3.11
3.11.4
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

2.27 KB, patch
Nelson Bolyard (seldom reads bugmail)
: review+
Wan-Teh Chang
: superreview+
Details | Diff | Splinter Review
(Assignee)

Description

11 years ago
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?
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.
(Assignee)

Comment 2

11 years ago
(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 :)
Feel free to submit a patch
(Assignee)

Comment 4

11 years ago
Created attachment 239634 [details] [diff] [review]
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.
Assignee: nobody → allan
Status: NEW → ASSIGNED
Attachment #239634 - Flags: review?
(Assignee)

Updated

11 years ago
Attachment #239634 - Flags: review? → review?(nelson)
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.
Attachment #239634 - Flags: review?(nelson) → review-
(Assignee)

Comment 6

11 years ago
(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 :-)
(Assignee)

Comment 7

11 years ago
Created attachment 240450 [details] [diff] [review]
Patch v2
Attachment #239634 - Attachment is obsolete: true
Attachment #240450 - Flags: review?(nelson)
Comment on attachment 240450 [details] [diff] [review]
Patch v2

r=nelson
Wan-Teh, do you concur?
Attachment #240450 - Flags: superreview?(wtchang)
Attachment #240450 - Flags: review?(nelson)
Attachment #240450 - Flags: review+
Priority: -- → P3
Target Milestone: --- → 3.11.4

Updated

11 years ago
Attachment #240450 - Flags: superreview?(wtchang) → superreview+
(Assignee)

Comment 9

11 years ago
So, I wonder... where do this patch go? Just to trunk? Then I'll check it in.
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 <allan@beaufour.dk>, 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).
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
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.