In nsprpub/pr/tests, All instances where $(DIST) would be used (ie make DIST=/....../) there is a $(PWD) in front of it, which causes it to fail. Switching to $(DIST) sounds like a proper fix.

What fails? What is the error message? In nsprpub/pr/tests/Makefile, we use $(PWD) in '-rpath $(PWD)/$(DIST)/lib' so that we pass an absolute pathname to the -rpath flag. ($(DIST) is a relative pathname.) Does this not work for you?

Setting all current Open/Normal to M4.

It's kind of a "doesn't work like the rest" type bug. I normally specify a absoulte pathname for DIST, and went to run a make test (neat failures on both glibc 2.1/x86 and /ppc) So I guess the Q is, why does the pr/tests dir need to use $(PWD)/$(DIST) and the rest (that get hit w/ make DIST=/usr/src/obj-mozilla/dist NSDISTMODE=copy NS_USE_GCC=1 MOZILLA_CLIENT=1 NO_MDUPDATE=1 NS_USE_NATIVE= USE_PTHREADS=1 export) go fine?

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Accepted the bug. Added cls@seawood.org to the cc list. The instructions to build NSPR and install it under some directory is actually a hack. NSPR doesn't have an 'install' makefile target that is common in many other software packages. But Chris Seawood discovered that by specifying 'DIST=<nspr-install-dir> NSDISTMODE=copy' one gets very close to that. Unfortunately, this is not really the way NSPR is intended to be built. It just happens to work. This is why it doesn't work when invoked from the nsprpub/pr/tests directory. If you just want to run NSPR tests, you can build both NSPR and NSPR tests without the 'DIST=<nspr-install-dir> NSDISTMODE=copy' options. Summary: the 'DIST' makefile variable is not designed to be overriden from the command line. The real fix is to make the 'install' makefile target work like the other software packages, so that we won't need to use the 'DIST=<nspr-install-dir> NSDISTMODE=copy' hack.

moving to m6

Marked the bug resolved-invalid. The workaround is to build both NSPR and NSPR tests without the 'DIST=<nspr-install-dir> NSDISTMODE=copy' options.

has this been reflected in the Makefile or the Readme, or will Joe Hacker have to know that s/he must manually unset these options?

Reopened the bug. I found a way to fix it.

I found a way to test whether a pathname is absolute or relative in gmake. Then I changed nsprpub/pr/tests/Makefile so that it only prepends $(PWD) to $(DIST)/lib when $(DIST) is a relative pathname. /cvsroot/mozilla/nsprpub/pr/tests/Makefile, revision 3.29. Marked the bug fixed. To verify the fix, do the following: % cd mozilla/nsprpub % gmake clean export DIST=/somedir DISTMODE=copy % cd pr/tests % gmake clean export DIST=/somedir DISTMODE=copy % cd XXXOS_DBG.OBJ % cvar # this is an NSPR test and see if you can run the test. Before, ld.so would complain that it couldn't find libplc3.so, etc.

Just checked it here (Linux 2.2.5/glibc 2.1/gnu make 3.77) and it works.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.