Closed Bug 103460 Opened 23 years ago Closed 23 years ago

Build fails on Win98 SE

Categories

(SeaMonkey :: Build Config, defect, P2)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: andy.ruddock, Assigned: netscape)

References

Details

Attachments

(1 file)

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
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
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?
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.
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).
cls says mozilla should build with cygwin perl too, leaving it as new.
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.
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. ***
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.
andy, can you try the patch i posted and see if it works for you on SE with both
versions of perl?
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
Closed: 23 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.

Attachment

General

Created:
Updated:
Size: