Closed
Bug 103460
Opened 23 years ago
Closed 23 years ago
Build fails on Win98 SE
Categories
(SeaMonkey :: Build Config, defect, P2)
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?
Reporter | ||
Comment 3•23 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•23 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).
cls says mozilla should build with cygwin perl too, leaving it as new.
Comment 6•23 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.
Assignee | ||
Comment 7•23 years ago
|
||
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•23 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. ;)
Assignee | ||
Updated•23 years ago
|
Severity: normal → critical
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
Assignee | ||
Comment 9•23 years ago
|
||
*** Bug 107304 has been marked as a duplicate of this bug. ***
Comment 10•23 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•23 years ago
|
||
Comment 12•23 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•23 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.
Assignee | ||
Comment 14•23 years ago
|
||
Patch has been checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•