Build fails on Win98 SE

VERIFIED FIXED in mozilla0.9.7

Status

SeaMonkey
Build Config
P2
critical
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: Andy Ruddock, Assigned: hacker formerly known as seawood@netscape.com)

Tracking

Trunk
mozilla0.9.7
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Mozilla 0.9.4 build fails on Win98 SE.

Output from build follows:

--- Output from build process - Start ---
w95make: Entering Directory C:\Develop\Mozilla\mozilla\modules\libreg\standalone
 with target export
reg.c
C:\Develop\Mozilla\mozilla\modules\libreg\standalone\reg.c(75) : fatal error C10
83: Cannot open include file: 'NSReg.h': No such file or directory
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\cl.exe' : return code
'0x2'
Stop.
w95make: nmake failed in directory standalone with error code 2
NMAKE : fatal error U1077: '..\..\config\w95make.exe' : return code '0x2'
Stop.
w95make: nmake failed in directory modules\libreg with error code 2
NMAKE : fatal error U1077: '.\config\w95make.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\BIN\N
MAKE.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\BIN\N
MAKE.exe"' : return code '0x2'
Stop.
--- Output from build process - End ---
This can be fixed by adding "$(MAKE_INSTALL) ..\include\*.h ." to the "docopy:"
section of modules\library\libreg\standalone\makefile.win

The build then fails with the following:
--- Output from build process - Start ---
w95make: Entering Directory C:\Develop\Mozilla\mozilla\xpcom\typelib\xpidl with
target export
xpidl.c
C:\Develop\Mozilla\mozilla\xpcom\typelib\xpidl\xpidl.h(174) : fatal error C1083:
 Cannot open include file: 'xpt_struct.h': No such file or directory
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\cl.exe' : return code
'0x2'
Stop.
w95make: nmake failed in directory xpidl with error code 2
NMAKE : fatal error U1077: '..\..\config\w95make.exe' : return code '0x2'
Stop.
w95make: nmake failed in directory typelib with error code 2
NMAKE : fatal error U1077: '..\config\w95make.exe' : return code '0x2'
Stop.
w95make: nmake failed in directory xpcom with error code 2
NMAKE : fatal error U1077: '.\config\w95make.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\BIN\N
MAKE.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\BIN\N
MAKE.exe"' : return code '0x2'
Stop.
--- Output from build process - End ---

I'm not sure what is required to fix this. I can see that the required header
file is at C:\Develop\Mozilla\mozilla\xpcom\typelib\xpt\public
Plus, I don't want to screw around too much just to get a buid on my machine.

The original 0.9.4 milestone release built ok. I don't have source going back
too far but the 20011002 source doesn't build either (same problem).

I'll try going back a day or so at a time and see if I can isolate where the
problem was introduced.

Building on Win98 SE, Visual C++ 6

Comment 1

17 years ago
This is related to the requires system. Which version of Perl are you using? If
you're using the one that comes with cygwin, please try using activestate's.
Don't bother trying to narrow down the introduction of this problem, it must
have surfaced when MOZ_TRACK_MODULE_DEPS was activated by default.

I've heard another report of this, could it be related to the fact that we're
indenting requires statements with tabs in most makefile.win files? Is indenting
with tabs ok, or should this be changed to conform to commonly used ways of
indenting?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

17 years ago
is this a fresh CVS?, I remember a failure in this directory when the echo win9x
problem was actual. I can build the CVS soruce from today under Win98. Did you
try to clobber the build?
(Reporter)

Comment 3

17 years ago
I "thought" I was using the ActiveState Perl, but checking my PATH it turned out
that the cygwin tools were earlier in the path.
I've corrected that and it seems to build ok now.
I've just got the source dated 10/06 from the ftp server and am building it now.
(Reporter)

Comment 4

17 years ago
That seems to have fixed it - I've now got a build that I can use. This bug can
probably be marked fixed (user error).

Comment 5

17 years ago
cls says mozilla should build with cygwin perl too, leaving it as new.

Comment 6

17 years ago
argh, win98 sucks. The command processor doesn't support cool syntax. I'm
wondering if we should switch over to jonsmirl's recommendation of using the
"dummy" that gets swallowed by the command processor.
I had FrodoB try smirl's echo.dummy suggestion and it didn't seem to work for
him.  Only switching to activestate perl seemed to do the trick.  I think the
perl statement just needs to be cleaned up to work for cygwin.

Comment 8

17 years ago
Actually, I think it *did* do the trick for me (Mark Anderson == FrodoB).  
However, it didn't expand all the includes paths; just the first one (at least 
as far as I could tell).  I'd have to try again to be sure, but I think it 
worked (I know I didn't try an entire build).

However, I reverted back to the way it is in the tree and am using ActiveState 
now.  Just didn't want to have all those M's come up in a cvs update. ;)
Severity: normal → critical
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
*** Bug 107304 has been marked as a duplicate of this bug. ***

Comment 10

17 years ago
i'm using the perl that came with cygnus (by accident, i assure you) and the fix
that worked for me was to s#/#\# in the XPDIST translation. I'll attach the
patch when i get to my windows machine. If it works with both activestate and
cygnus perl, i think we should go with it, but i'm happy to be told of a better way.

Comment 11

17 years ago
Created attachment 55947 [details] [diff] [review]
simply s#\\#\/# in the xpdist translation works for both activestate and cygwin perl, and the path delimiters seem to be interchangeable.

Comment 12

17 years ago
andy, can you try the patch i posted and see if it works for you on SE with both
versions of perl?
(Reporter)

Comment 13

17 years ago
Sorry for the delay, caught me on a day I wasn't at the PC!

Reverted to the source for the 0.9.5 release, I know that produces a stable
product, and the patch works with both ActiveState and Cygwin.

Of course, if you have Cygwin in the path prior to ActiveState you still need to
ensure that WinCVS is used rather than Cygwin CVS unless you've done a fresh
pull using Cygwin - as per the Win32 build instructions.
Patch has been checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.