Closed Bug 1816 Opened 21 years ago Closed 19 years ago

nsprpub doesn't understand latest cygwin uname

Categories

(NSPR :: NSPR, defect, P2)

4.0.2
x86
Windows NT
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tague, Assigned: wtc)

References

Details

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.
Status: NEW → ASSIGNED
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
Target Milestone: M4 → 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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Target Milestone: M6 → ---
uname -s returns "CYGWIN_98-4.10" with the latest cygwin tools (under win95)
which is not recognised properly.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** 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
QA Contact: phillip → wtc
Status: REOPENED → ASSIGNED
Target Milestone: --- → 4.2
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → FIXED
Version: other → 4.0.2
You need to log in before you can comment on or make changes to this bug.