Closed Bug 1565577 Opened 3 months ago Closed 3 months ago

Visual Studio's cl.exe -? hangs on Windows x64 when building nss since changeset 9162c654d06915f0f15948fbf67d4103a229226f

Categories

(NSS :: Build, defect, P1)

3.45
x86_64
Windows
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mikekaganski, Assigned: mikekaganski)

References

Details

Attachments

(1 file)

In bug 1554616, a check for lcc was added for 64-bit platforms using a call to $(CC) -? 2>&1 >/dev/null. When using MS compiler on cygwin, this command results in cl.exe hanging infinitely, waiting for user input (the redirection to /dev/null obviously affects that, since calling 'cl.exe -?' in cygwin console doesn't start an interactive output - unlike cmd.exe; and also using redirection to a dummy file also gives non-interactive output).

This effectively breaks building 64-bit nss on Windows. See thread starting at https://lists.freedesktop.org/archives/libreoffice/2019-July/083122.html

Proposal is to also redirect stdin to /dev/null, which fixes the problem with MS compiler.

It sounds like this needs to be back-ported to NSS 3.45. Will this need its own point release?

Assignee: nobody → mikekaganski
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1
Attachment #9077675 - Flags: review?(shigorin)
Attachment #9077675 - Flags: review?(jjones)
Comment on attachment 9077675 [details] [diff] [review]
nss.fix-freebl-add-lcc-support.patch.1

Not sure about my review flag handling but I'm fine with this patch :-) (and lcc 1.23.12 is fine with it, too)
Attachment #9077675 - Flags: review?(shigorin) → review+
Attachment #9077675 - Flags: review?(jjones) → review+

OK, build came back clean. I'll land it on default now.

Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 3.46

NSS_3_45_BRANCH: https://hg.mozilla.org/projects/nss/rev/a777f84f4a754f26e6c025c1c9876994a6e93124

Right now I'll plan to treat this as a ridealong for a potential 3.45 patch release. Please needinfo me if you think this is severe enough to warrant a .1 release on its own. Thanks!

Just a drive-by comment on this one... $(CC) -? 2>&1 >/dev/null </dev/null doesn't work quite as intended. stderr will not be directed to /dev/null as it appears the intent is. To get that you need $(CC) -? >/dev/null 2>&1 </dev/null.

(In reply to Martin Thomson [:mt:] from comment #7)

I suppose that it works just quite as intended, i.e. redirecting stderr to where was stdout, and then redirecting stdout to /dev/null. Otherwise, trying to parse some output of a program with all *outs redirected to /dev/null wouldn't make much sense.

Mike, indeed.

You need to log in before you can comment on or make changes to this bug.