MOZ_MAKE_FLAGS=-j2 doesn't work with gnumake on windows

RESOLVED FIXED in mozilla1.1alpha


17 years ago
14 years ago


(Reporter: tvl, Assigned: netscape)



Windows 2000

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



17 years ago
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   -
Ic:/stockmoz/mozilla/dist/include/nspr -I../../pr/include -
I../../pr/include/private  threads/combined/./pruthr.c
make[7]: Leaving directory 
cl -Foprdump.obj -c     -W3 -nologo -GF -Gy -MD -O2   -UDEBUG -U_DEBUG  -
Ic:/stockmoz/mozilla/dist/include/nspr -I../../../pr/include -
I../../../pr/include/private  prdump.c
threads/combined/./pruthr.c(1319) : warning C4700: local variable 'status' used 
without having been initialized
make[5]: *** No rule to make target `nspr4.lib'.  Stop.
make[5]: *** Waiting for unfinished jobs....
rc.exe -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 -
Ic:/stockmoz/mozilla/dist/include/nspr -I../../pr/include -
I../../pr/include/private -Fonspr.res nspr.rc

make[5]: *** Waiting for unfinished jobs....
make[5]: *** Waiting for unfinished jobs....
./nspr.res finished
make[6]: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub/pr/src/threads'

make[5]: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub/pr/src'
make[4]: *** [export] Error 2
make[4]: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub/pr'
make[3]: *** [export] Error 2
make[3]: Leaving directory `/cygdrive/c/stockmoz/mozilla/nsprpub'
make[2]: *** [nspr] Error 2
make[2]: Leaving directory `/cygdrive/c/stockmoz/mozilla'
make[1]: *** [default] Error 2
make[1]: 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?

Comment 2

17 years ago
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.


Comment 4

17 years ago
bug 133521 filed for ldap.  close this out as a dup of bug 123424?
Does the rest of the build work besides nspr & ldap?  If so, close it out.

Comment 6

17 years ago
  MAKE := $(patsubst -j%,,$(MAKE)) -j1
to directory/c-sdk/ldap/ 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.)
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
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

Target Milestone: mozilla1.2alpha → mozilla1.0.1

Comment 8

17 years ago
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.
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
Attachment #78309 - Attachment is obsolete: true
Blocks: 138348
Comment on attachment 79928 [details] [diff] [review]
win32 make -j v2

Attachment #79928 - Flags: review+
The patch has been checked in on the trunk.
Keywords: adt1.0.0, mozilla1.0
Whiteboard: [fixed on trunk]

Comment 17

17 years ago
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?

Comment 19

17 years ago
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


17 years ago
Keywords: topembed → topembed+
Whiteboard: [fixed on trunk] → [fixed on trunk][drivers queue]
Giving up on drivers.
No longer blocks: 138348
Last Resolved: 16 years ago
Resolution: --- → FIXED
Whiteboard: [fixed on trunk][drivers queue]
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.