MOZ_MAKE_FLAGS=-j2 doesn't work with gnumake on windows. seems there's an order problem, build dies early on as follows: [...] cl -Fothreads/combined/./pruthr.obj -c -W3 -nologo -GF -Gy -MD -O2 - UDEBUG -U_DEBUG -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 - D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ - Ic:/stockmoz/mozilla/dist/include/nspr -I../../pr/include - I../../pr/include/private threads/combined/./pruthr.c pruthr.c make: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub/pr/src/threads/combined' cl -Foprdump.obj -c -W3 -nologo -GF -Gy -MD -O2 -UDEBUG -U_DEBUG - DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 - D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ - Ic:/stockmoz/mozilla/dist/include/nspr -I../../../pr/include - I../../../pr/include/private prdump.c prdump.c threads/combined/./pruthr.c(1319) : warning C4700: local variable 'status' used without having been initialized make: *** No rule to make target `nspr4.lib'. Stop. make: *** Waiting for unfinished jobs.... rc.exe -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 - D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ - Ic:/stockmoz/mozilla/dist/include/nspr -I../../pr/include - I../../pr/include/private -Fonspr.res nspr.rc make: *** Waiting for unfinished jobs.... make: *** Waiting for unfinished jobs.... ./nspr.res finished make: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub/pr/src/threads' make: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub/pr/src' make: *** [export] Error 2 make: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub/pr' make: *** [export] Error 2 make: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub' make: *** [nspr] Error 2 make: Leaving directory `/cygdrive/c/stockmoz/mozilla' make: *** [default] Error 2 make: Leaving directory `/cygdrive/c/stockmoz/mozilla' make: *** [build] Error 2
This looks like bug 123423. A workaround was checked into the trunk a week or so ago. Can you try it on your branch build to see if it clears up the problem?
123424 fixes it for nspr, but it fails in ldap now (nsldab32v40.lib). do you want me to move this comment over to bug 123424 and then you can close this out as a dup?
File a separate bug on the ldap product. They use a different build system that piggy backs ontop of NSPR's build system and that's what's causing the problem here. Strangely enough, we don't see that particular problem when using -j4 on linux. You may be able to get away with a hack similar to the one done for NSPR.
Does the rest of the build work besides nspr & ldap? If so, close it out.
adding: MAKE := $(patsubst -j%,,$(MAKE)) -j1 to directory/c-sdk/ldap/Makefile.in get's ldap building, but it fails next in js. so i get the feeling there's something that just doesn't work with the baseline rules for win32 gmake and -j2. (in js it's failing in the same way, it wants js3250.lib and it hasn't been built yet.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla1.2alpha
So I looked at this a bit closer and it appears that the problem is triggered by IMPORT_LIBRARY. IMPORT_LIBRARY is the .lib stub library that have you have to actually link against on win32 & OS/2 when you want to link against a dll. On win32, this library is automatically generated when the dll is created. On OS/2, it appears as though IMPORT_LIBRARY is built in a separate step so we have an OS/2 only make target for IMPORT_LIBRARY. mkaply, can you confirm that the extra ruleset is still needed? The problem in -jx builds is that both SHARED_LIBRARY & IMPORT_LIBRARY are listed as dependencies of libs::. On non -j1 builds, this isn't a problem as SHARED_LIBRARY is listed first so IMPORT_LIBRARY has been built by time the dependency is checked. What I'm seeing in -jx builds is that the dependencies of libs:: are being evaluated in parallel so the build attempts to build IMPORT_LIBRARY before SHARED_LIBRARY has finished. If I remove IMPORT_LIBRARY from the dependency list, js builds fine with -j2. An alternative fix is to add a win32 dummy ruleset for IMPORT_LIBRARY that consists of just a dependency upon SHARED_LIBRARY.
Target Milestone: mozilla1.2alpha → mozilla1.0.1
We definitely need a separate target for the IMPORT_LIB because it happens in a separate step.
So after adding the stub IMPORT_LIBRARY rule for win32 and fixing some dependency problems when calling midl, I ran into another problem. Anyone know exactly what these .pdb files are used for? When building jpeg, I ran into the problem that both files being compiled were attempting to write to jpeg3250.pdb. I added a hack to use .NOTPARALLEL: if PDBFILE is defined and that seems to get around the problem for now.
pdb is described in http://support.microsoft.com/default.aspx?scid=kb;EN-US;q121366
Created attachment 78309 [details] [diff] [review] win32 make -j v1 So I'm not sure how useful this make -j support really is. We appear to use PDBFILE by default in a lot of places. It's definitely turned on in debug/profile builds.
Comment on attachment 78309 [details] [diff] [review] win32 make -j v1 so, this essentially makes -j have no effect, but that's better than failing to build. r=bryner.
Attachment #78309 - Flags: review+
Hmm. So I looked at this again and we use -Fd$(PDBFILE) by default everywhere. However, xpcom built fine with -j and jpeg didn't. It looks like even though we specify -Fd, it isn't used (atm) unless you build with debugging info. Jpeg adds -Zi, supposedly for mmx support, which adds debug info to the pdb. If I remove the -Zi then jpeg compiles with -j just fine. Not sure if we should change the patch or not.
Created attachment 79928 [details] [diff] [review] win32 make -j v2 Only off -j if MOZ_DEBUG or MOZ_PROFILE are set. Turn it off always for jpeg & xpconnect since they use certain compiler flags that actually touch the .pdb files.
Attachment #78309 - Attachment is obsolete: true
Comment on attachment 79928 [details] [diff] [review] win32 make -j v2 r=bryner
Attachment #79928 - Flags: review+
The patch has been checked in on the trunk.
Keywords: adt1.0.0, mozilla1.0
Whiteboard: [fixed on trunk]
Why do we need to implement this on the branch at this time? Do we plan to ship beta using gmake on Windows?
This is just one of a growing list of build fixes (see bug 138348) that aren't critical for releasing the beta to end-users but are wanted for our "long-lived" 1.0 branch that we're recommending to embeddors. And we are only recommending the gmake builds to embeddors. So the fix doesn't have to go in *right now* but it does need to go into the 1.0 branch at some point. Should I be using adt1.0.1 for these non-end-user affecting but branch-bound fixes instead?
This is not needed for MachV beta, based on Seawood's comments adt1.0.0-. Pls get hit in after MachV branches for beta.
Keywords: adt1.0.0 → adt1.0.0-, topembed
Whiteboard: [fixed on trunk] → [fixed on trunk][drivers queue]
Giving up on drivers.
No longer blocks: 138348
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Whiteboard: [fixed on trunk][drivers queue]
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
You need to log in before you can comment on or make changes to this bug.