Win32 Build fails with alternate objdir.

RESOLVED FIXED in 4.6

Status

defect
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: wasti.redl, Assigned: wtc)

Tracking

other
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

15 years ago
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.
Reporter

Comment 1

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

Comment 2

15 years ago
It seems very likely to me that some part of your configuration is unusual.
People build winxp with the .net compilers every day.
Reporter

Comment 3

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

Comment 4

15 years ago
Using an objdir is not unusual, it is the recommended configuration.

Comment 5

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

Comment 6

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

Updated

15 years ago
Assignee: nobody → wtchang
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: core.build-config → wtchang
Assignee

Comment 7

15 years ago
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)

Updated

15 years ago
Attachment #170192 - Flags: review?(cls) → review+
Assignee

Comment 8

15 years ago
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 ago15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.6
You need to log in before you can comment on or make changes to this bug.