274751 - Win32 Build fails with alternate objdir.

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Sebastian Redl]

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.

Comment 1

[Sebastian Redl]

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

[Benjamin Smedberg]

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

Comment 3

[Sebastian Redl]

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

[Benjamin Smedberg]

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

Comment 5

[cls]

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.

Comment 6

[cls]

Apparently, nspr.res doesn't get removed with a 'make distclean'.  That's a
valid bug.

Comment 7

[Wan-Teh Chang]

Attachment: Proposed patch

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).

Comment 8

[Wan-Teh Chang]

I checked in the patch on the NSPR trunk (NSPR 4.6)
and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.8 Alpha 6).