The nsprpub build configuration doesn't parse the uname results for the latest Cygwin release. The latest cygwin uname returns CYGWIN-NT4.0 as a result string instead of WINNT. Since we suggest using these tools for building Mozilla we should support the CYGWIN-* result as well.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

moving to m6

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

I am assuming the place where the change is needed is somewhere in here: /nsprpub/config/arch.mk, line 178 -- # If uname -s returns "Windows_NT", we assume that we are using /nsprpub/config/arch.mk, line 179 -- # the uname.exe in MKS toolkit. /nsprpub/config/arch.mk, line 181 -- # The -r option of MKS uname only returns the major version number. /nsprpub/config/arch.mk, line 183 -- # Moreover, it doesn't have the -p option, so we need to use uname -m. /nsprpub/config/arch.mk, line 187 -- OS_MINOR_RELEASE := $(shell uname -v) /nsprpub/config/arch.mk, line 192 -- CPU_ARCH := $(shell uname -m) /nsprpub/config/arch.mk, line 194 -- # MKS's uname -m returns "586" on a Pentium machine. /nsprpub/config/arch.mk, line 201 -- # If uname -s returns "CYGWIN32/NT", we assume that we are using /nsprpub/config/arch.mk, line 202 -- # the uname.exe in the GNU-Win32 tools. /nsprpub/config/arch.mk, line 206 -- CPU_ARCH := $(shell uname -m) /nsprpub/config/arch.mk, line 208 -- # GNU-Win32's uname -m returns "i686" on a Pentium Pro machine. Unfortunately, I do not have a Windows NT 4.0 machine to test this on, so it is hard for me to be sure... But I'd still be interested to know if this helps. BTW, this applies not only to nsprpub--I believe it applies to the whole of Mozilla as well--correct me if I'm mistaken.

I downloaded and installed the latest Cygwin release (Beta 20.1). Its 'uname -s' returns 'CYGWIN_NT-4.0' on our NT 4.0 machine and 'CYGWIN_95-4.0' on our Win95 machine. Note that that string contains both the OS name and release number. As zuperdee@penguinpowered.com pointed out, the relevant makefile is mozilla/nsprpub/config/arch.mk. I added some code to handle the new return format of Cygwin's uname command. Since nsprpub is the only Mozilla component that uses a GNU make based, cross-platform build system, I suspect that the rest of Mozilla isn't affected by this problem. The fix is checked into the tip: /cvsroot/mozilla/nsprpub/config/arch.mk, revisions 3.10 and 3.11.

Merged the fix into the internal cvs repository. /m/src/nspr20/config/arch.mk, revision 2.12.

this fix is not visible to qa. if you think this bug should be reopened, please do so. will mark as verified.

uname -s returns "CYGWIN_98-4.10" with the latest cygwin tools (under win95) which is not recognised properly.

*** Bug 49531 has been marked as a duplicate of this bug. ***

phillip is no longer @netscape.com changing qa contact to default for this component

I checked in a fix on the tip of NSPR that allows building on Windows 98 with the MKS or Cygwin tools. /cvsroot/mozilla/nsprpub/config/arch.mk, revision 3.20. Note that the Mozilla client build is using NSPRPUB_CLIENT_BRANCH so it won't get this fix unless we merge the fix on that branch.