A number of windows tinderboxes using the MSYS platform give the errors like this: make: Entering directory `/e/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/obj-fx-trunk/xpcom/stub' link -NOLOGO -DLL -OUT:xpcom.dll -PDB:xpcom.pdb -SUBSYSTEM:WINDOWS nsXPComStub.obj ./module.res -LTCG -NXCOMPAT -SAFESEH -MANIFEST:NO -DEBUG -OPT:REF -OPT:nowin98 ../../dist/lib/xul.lib ../../dist/lib/nspr4.lib ../../dist/lib/plc4.lib ../../dist/lib/plds4.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib Creating library xpcom.lib and object xpcom.exp LINK : fatal error LNK1104: cannot open file 'xpcom.lib' set -e; \ ( echo nspr4.dll; echo plc4.dll; echo plds4.dll; echo sqlite3.dll; echo nssutil3.dll; echo softokn3.dll; echo nss3.dll; echo ssl3.dll; echo smime3.dll; echo js3250.dll; echo xul.dll; ) > ../../dist/bin/dependentlibs.list make: *** [xpcom.dll] Error 80 make: *** Deleting file `xpcom.dll'
FWIW, I get this from time to time when doing my own personal builds as well.
(In reply to comment #1) > FWIW, I get this from time to time when doing my own personal builds as well. Are you using MozillaBuild 1.2 ? What about the VC compiler version ? This describes the tinderbox setup: http://wiki.mozilla.org/ReferencePlatforms/Win32#January_2008_Update.2FRefresh If there are significant differences then this could be some sort of build system glitch.
I'm using VC8 SP1 and the same MSYS setup as MozillaBuild 1.2
We are seeing these sporadically in our win2k builder as well. See http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1218223367.1218223518.12078.gz#err0
Nothing here so far says whether this has been seen to happen with or without changes to the source code. We've just seen this on SeaMonkey and Thunderbird trunk builds when Benjamin pushed the following changeset: http://hg.mozilla.org/index.cgi/mozilla-central/rev/2cdac4c2a023 No idea if this will help or not...
There is a "warning: -jN forced in submake: disabling jobserver mode." which appears in the broken build logs which is a bit suspicious, but I can't figure out how that would actually cause the error being reported.
And it happened once more, this time, the changeset was: http://hg.mozilla.org//mozilla-central/index.cgi/rev/c823327ec9e0
I don't think the changeset has much to do with it, other than it make something in XPCOM rebuild.
I'm still seeing this from time to time: (maybe on the following TB/Win box only !?) http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1225449412.1225449599.20918.gz Win2k3 comm-central check on 2008/10/31 03:36:52 link -NOLOGO -DLL -OUT:xpcom.dll -PDB:xpcom.pdb -SUBSYSTEM:WINDOWS nsXPComStub.obj ./module.res -NXCOMPAT -SAFESEH -DYNAMICBASE ../../dist/lib/xpcom_core.lib d:/buildbot/trunk-win32/build/objdir-tb/mozilla/dist/lib/nspr4.lib d:/buildbot/trunk-win32/build/objdir-tb/mozilla/dist/lib/plc4.lib d:/buildbot/trunk-win32/build/objdir-tb/mozilla/dist/lib/plds4.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib Creating library xpcom.lib and object xpcom.exp NEXT ERROR LINK : fatal error LNK1104: cannot open file 'xpcom.lib'
Dietrich added [orange] because this is affecting the WinCE builds which were enabled a couple of days ago. Google searches implicate a race condition in mspdbsvr when using parallel make, which is poor because parallel make is precisely what mspdbsvr is designed to support. This is all very strange because we set -j4 on the equivalent win32 builds, although they use VC2008 rather than VS2008. We don't use -jN on the WinMo builds currently. I'm going to try backing off from -j4 to -j2 for the WinCE builds in the first instance, and if that doesn't help then disable parallel make altogether.
We keep hitting this, this is at least the second time today: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1250880719.1250882675.25649.gz
I've removed parallel make from the mozconfig for WinCE builds: http://hg.mozilla.org/build/buildbot-configs/rev/a2fbf9c38253 (In reply to comment #10) Meant to say that we use make -j4 with VS2005 just fine, it's just VS2008 that seems to cause problems.
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1254785908.1254786489.26830.gz WINNT 5.2 comm-1.9.1 unit test on 2009/10/05 16:38:28
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1257202246.1257205425.946.gz WINNT 5.2 mozilla-1.9.2 build on 2009/11/02 14:50:46
So we could be running out of space on C here. moz2-win32-slave31 just died with a similar error, and had 681 MB free on C.
Merging with 509960 which has more analysis.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 509960
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.