The current CVS head (2004-12-15, approx. 10:00 AM GMT) fails to build under the following conditions: 1) Build System: Win32 Visual C++ 7.1 (.Net 2003) 2) OS: WinXP SP2 3) Mozilla base directory: D:\mozsource\ 4) Mozilla configuration entries: GLIB_PREFIX=d:/mozsource/mozbuildtools/vc71idl/glib LIBIDL_PREFIX=d:/mozsource/mozbuildtools/vc71idl/libidl mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/suiteobj mk_add_options MOZ_CO_PROJECT=suite ac_add_options --enable-application=suite mk_add_options MOZ_MAKE_FLAGS=-j2 ac_add_options --enable-svg ac_add_options --enable-svg-renderer-gdiplus ac_add_options --enable-xpctools ac_add_options --disable-optimize ac_add_options --enable-debug #END MOZCONFIG The build will fail at least on the following actions: 1) Linking together the object files resulting from the $srcbase/mozilla/nsprpub/pr/src directory. Error Message: Could not find file nspr.res. Suspected Reason: Resource compiler call is misconfigured in the build script and does not respect the object file directory. nspr.res is the result of compiling nspr.rc and should reside in $srcbase/mozilla/suiteobj/nsprpub/pr/src, but the actual location is $srcbase/mozilla/nsprpub/pr/src. Apparently the output of the resource compiler is misplaced and therefore not found by the linker. This can be confirmed by copying the file to the correct location and resuming the build process: linking will then succeed. 2) Linking together the object files resulting from the $srcbase/mozilla/nsprpub/lib/ds directory. Error Message: Could not find file plds.res. Suspected Reason: Same as 1) Workaround: Don't use an alternate object file directory. (I've removed the MOZ_OBJDIR instruction from the config and so far it compiles just fine.) Resolution: Locate resource compiler call in build rules and instruct to respect object file directory. Severity set to normal because easy workaround exists.
I believe the error must be somewhere in $srcbase/mozilla/nsprpub/config/rules.mk around line 363. How is $RES created? I have a strong feeling that it doesn't include the object dir. It doesn't come from within rules.mk, though. Hmm, this is strange. $srcbase/mozilla/nsprpub/pr/src/Makefile (that's one that failed) contains these two lines (324, 325): RES=$(OBJDIR)/nspr.res RESNAME=nspr.rc So RES should be ok. I'm afraid this requires someone who understands the build system better than I do.
It seems very likely to me that some part of your configuration is unusual. People build winxp with the .net compilers every day.
Indeed something is unusual: I have an alternate objdir. I have posted the full configuration, but the error occurs in the NSPR, so stuff like XPC and SVG should have no influence at all. I have posted my complete configuration.
Using an objdir is not unusual, it is the recommended configuration.
As Ben said, building in an alternate objdir is the recommended build configuration. I tested it and it still works as expected. If nspr.res exists in your source dir, then it's because you didn't do a 'make distclean' before switching to an objdir build. You must make sure that your build tree is in a pristine state before changing from srcdir to objdir builds. Due to the VPATH feature of make, files that exist in the srcdir will satisfy the makefiles requirement for the file. Then later commands which expect the file to exist in the current directory will fail.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Apparently, nspr.res doesn't get removed with a 'make distclean'. That's a valid bug.
Status: RESOLVED → UNCONFIRMED
Component: Build Config → NSPR
Product: Mozilla Application Suite → NSPR
Resolution: INVALID → ---
Version: Trunk → other
Assignee: nobody → wtchang
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: core.build-config → wtchang
Thanks for pointing out the problem, cls. I introduced this bug when fixing bug 242741 (rev. 3.57 of mozilla/nsprpub/config/rules.mk). In that fix, $(RES) is no longer part of $(OBJS). So we will need to remove $(RES) as well in all makefile targets that remove $(OBJS).
Attachment #170192 - Flags: review?(cls)
I checked in the patch on the NSPR trunk (NSPR 4.6) and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.8 Alpha 6).
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.6
You need to log in before you can comment on or make changes to this bug.