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

Status: RESOLVED FIXED

(NSS :: Build, defect, P1)

Description

[Mike Kaganski]

Attachment: nss.fix-freebl-add-lcc-support.patch.1

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.

Comment 1

[J.C. Jones [:jcj] (he/him)]

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

Comment 2

[J.C. Jones [:jcj] (he/him)]

Try push: https://treeherder.mozilla.org/#/jobs?repo=nss-try&revision=7023b92c7655

Comment 3

[Michael Shigorin]

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)

Comment 4

[J.C. Jones [:jcj] (he/him)]

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

Comment 5

[J.C. Jones [:jcj] (he/him)]

https://hg.mozilla.org/projects/nss/rev/a14882aaae9706c6c0c2c2cb615a3083889f56b4

Comment 6

[J.C. Jones [:jcj] (he/him)]

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!

Comment 7

[Martin Thomson [:mt:]]

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.

Comment 8

[Mike Kaganski]

(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.

Comment 9

[Michael Shigorin]

Mike, indeed.