Closed Bug 294333 Opened 16 years ago Closed 16 years ago

NSS fails to build with cygwin on Windows ME (MSVC6 SP5)

Categories

(NSS :: Build, defect)

x86
Windows ME
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED
3.10.2

People

(Reporter: piskozub, Assigned: wtc)

Details

Attachments

(2 files)

For several weeks I am unable to build mozilla suite (CVS trunk) on Windows ME.
It builds OK with --disable-crypto. However with normal settings (including
--enable-crypto) the build crashes in /mozilla/security/nss.

I'll attach the full output of "make all" done in /mozilla/security/manager
folder. It crashes exactly the same as the full build (at least the last screen
is the same).
Please take note that MS linker (cl.exe) gets a wrong option (Ld instead of LD)
in mozilla/security/nss/cmd/shlibsign. Also earlier I get a series of errors
including an "unknown processor architekture" in
mozilla/security/nss/lib/softoken and
mozilla_source/mozilla/security/nss/lib/nss plus a linker syntax error in
mozilla_source/mozilla/security/nss/lib/ssl
I'll add that the build machine is a Pentium 4. I build mozilla also on another
Windows ME box (Pentium 3) without problems (the settings are practically
identical, including the same versions of O/S, cygwin and MSVC). I'm not sure
what the difference may be (unless it is using different drives for building
mozilla (D: in case of the "bad" machine, C: on the "good" one).
What's the output of "uname -a" on this machine?
I'll check it tomorrow morning (European time) when I'll have access to that
"bad" computer. Now, I can say the its "good" twin (well, almost twin) responds
with:
WIN95 [HOST_NAME_CHANGED] 4.90 73010104 xx I386
Thanks.  From that output I concluded that on the "good twin"
you are using the uname command from Netscape wintools.

I suspect that on the "bad twin" you are using Cygwin's uname
command.  I suspect that "uname -s" probably says something
like CYGWIN_ME-x.xx.  If so, could you modify
mozilla/security/coreconf/arch.mk and add a section for
CYGWIN_ME-x.xx (replace x.xx with what "uname -s" returns)
that looks like the sections for CYGWIN_95-4.0 and CYGWIN_98-4.10?
Status: NEW → ASSIGNED
Yes, you must be right. 

I recently changed the PATH on the bad machine, because the windows "sort"
command started crashing cygwin bash, by moving d:\cygwin\bin to the front. The
sort crash was solved and that is when I discovered this problem. I wrongly
assumed that it started in the time I could not build mozilla due to the other
problem.

Actually in doing this I tried to copy the PATH sequence from the "good" twin
but I did a mistake. I see now that the good one has 
PATH=C:\PROGRA~1\MICROS~2\COMMON\MSDEV98\BIN;C:\PROGRA~1\MICROS~2\VC98\BIN;C:\PROGRA~1\MICROS~2\COMMON\TOOLS\WIN95;C:\PROGRA~1\MICROS~2\COMMON\TOOLS;C:\WINDOWS\SYSTEM;D:\WINTOOLS\BIN;C:\CYGWIN\BIN;C:\CYGWIN\USR\X11R6\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\PROGRA~1\NETWOR~1\PGP;
meaning that not only cygwin is before c:\windows but wintools are in front of
cygwin (I am sure I forgot to move wintools when moving cygwin).

Tomorrow, I will modify arch.mk as suggested (even as I know now how to solve
the problem by changing the PATH sequence).

A note to myself: the only PATH sequence which now works on Windows ME is:
MSVC; wintools; cygwin; windows\command; (the Microsoft sort.exe resides here)
while windows; and windows\system; may be practically anywhere in the sequence
BTW, the cygwin uname on the "good twin" responds with:

CYGWIN_ME-4.90 turquoise 1.5.16(0.128/4/2) 2005-04-25 20:26 i686 unknown unknown
Cygwin

so I'm going to add tomorrow the following section to arch.mk:

ifeq ($(OS_ARCH),CYGWIN_ME-4.90)
	OS_ARCH   = CYGWIN_NT-4.0
	OS_TARGET = WIN95
endif
Attached patch Proposed patchSplinter Review
Give this patch a try, and let me know if it works
on Windows Me (with Cygwin's uname).
The patch works. A fresh CVS tree build of the suite went OK.

Is there a chance of checking in this extremely non-risky patch before 1.8b2?
Comment on attachment 183780 [details] [diff] [review]
Proposed patch

Please review.	This patch allows building NSS on Windows Me.
Attachment #183780 - Flags: superreview?(nelson)
Attachment #183780 - Flags: review?(cls)
Comment on attachment 183780 [details] [diff] [review]
Proposed patch

I'm not a cygwin user, but considering the similarity of these new lines to the
ones preceeding them, it looks like it shold work.  Jacek has confirmed that it
works.	Thanks Jacek.
Attachment #183780 - Flags: superreview?(nelson) → superreview+
Attachment #183780 - Flags: review?(cls) → review+
Jacek, I will request 1.8b3 approval because I check in
NSS fixes for Mozilla in batches.

I am surprised that it is still possible to build Mozilla
on Windows 9x :-)

Nelson, I've checked this patch in on the NSS trunk for
NSS 3.10.1.

Checking in arch.mk;
/cvsroot/mozilla/security/coreconf/arch.mk,v  <--  arch.mk
new revision: 1.18; previous revision: 1.17
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.10.1
Comment on attachment 183780 [details] [diff] [review]
Proposed patch

Requesting mozilla1.8b3 and aviary1.1a2 approvals.

This is a simple, low-risk makefile change to enable
building NSS on Windows Me.  The patch has been reviewed
by cls and Nelson Bolyard and verified by the bug reporter.
Attachment #183780 - Flags: approval1.8b3?
Attachment #183780 - Flags: approval-aviary1.1a2?
Status: RESOLVED → VERIFIED
Comment on attachment 183780 [details] [diff] [review]
Proposed patch

a=shaver
Attachment #183780 - Flags: approval1.8b3?
Attachment #183780 - Flags: approval1.8b3+
Attachment #183780 - Flags: approval-aviary1.1a2?
Attachment #183780 - Flags: approval-aviary1.1a2+
Target Milestone: 3.10.1 → 3.10.2
Summary: NSS fails to build on Windows ME (MSVC6 SP5) → NSS fails to build with cygwin on Windows ME (MSVC6 SP5)
You need to log in before you can comment on or make changes to this bug.