Closed Bug 88169 Opened 23 years ago Closed 18 years ago

Build failure when source is read-only: nfspwd

Categories

(NSS :: Build, defect, P2)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 311074

People

(Reporter: BenB, Assigned: wtc)

References

Details

Reproduction:
1. Set --enable-crypto
2. Pull mozilla 0.9.2 branch
3. cd ..; mkdir bin; chown user2:user2 bin; cd bin; su user2
4. build

Actual result:
Build fails:

make[3]: Entering directory
`/mnt/compile/linux/beonex-0.7-dev-1/mozilla/security/coreconf/nsinstall'
gcc [...] /usr/src/beonex-0.7-dev-1/bin1/nss/nsinstall.c
gcc [...] pathsub.c
gcc -o /usr/src/beonex-0.7-dev-1/bin1/nss/nsinstall [...]
rm -f nfspwd; cp nfspwd.pl nfspwd; chmod +x nfspwd
rm: Removal (unlink) of ?nfspwd? not possible: No permission
cp: usual file ?nfspwd? couldn't be created: No permission
chmod: During setting of access rights of ?nfspwd?: Operation not allowed
make[3]: *** [nfspwd] Error 1
make[3]: Leaving directory
`/mnt/compile/linux/beonex-0.7-dev-1/mozilla/security/coreconf/nsinstall'
make[2]: *** [libs] Error 2

(manually translated into English)

Expected result:
Successful build
*** Bug 88170 has been marked as a duplicate of this bug. ***
Try this patch please.

Index: Makefile
===================================================================
RCS file: /cvsroot/mozilla/security/coreconf/nsinstall/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile    2001/04/24 16:45:53     1.3
+++ Makefile    2001/06/28 05:27:51
@@ -38,7 +38,7 @@

 CSRCS          = nsinstall.c pathsub.c

-PLSRCS         = nfspwd.pl
+#PLSRCS                = nfspwd.pl

 PROGRAM                = nsinstall
Status: NEW → ASSIGNED
Yes, the patch wfm. Thanks for the fast response!
Ben, we won't be able to fix this in NSS_CLIENT_TAG soon.
Meantime, you can use the follwing workaround.

After you check out the Mozilla source tree, you touch
the file mozilla/security/coreconf/nsinstall/nfspwd to
give it a newer timestamp than
mozilla/security/coreconf/nsinstall/nfspwd.pl.  For
example,
    % cvs co mozilla/client.mk
    % cd mozilla
    % gmake -f client.mk checkout
    % touch security/coreconf/nsinstall/nfspwd

Assigned the bug to Bob.  Bob, these rules in coreconf/rules.mk
require write access to the source tree and breaks the BUILD_TREE
build method if the source tree is read-only:
%: %.pl
        rm -f $@; cp $*.pl $@; chmod +x $@

%: %.sh
        rm -f $@; cp $*.sh $@; chmod +x $@

(By the way, the $*.pl and $*.sh in the rules should be replaced
by $<.)

I don't know whether these two rules are useful at all.  We can
delete them and always invoke a script as follows:
        $(PERL) foo.pl
        sh foo.sh

Or we can put the no-suffix target in $(OBJDIR):
$(OBJDIR)/%: %.pl
        rm -f $@; cp $< $@; chmod +x $@

$(OBJDIR)/%: %.sh
        rm -f $@; cp $< $@; chmod +x $@

If we put the no-suffix versions of the scripts in $(OBJDIR),
makefiles that invoke them will need to be modified to use
the new pathnames (e.g., the NFSPWD variable in
coreconf/command.mk).
Assignee: wtc → relyea
Status: ASSIGNED → NEW
Priority: -- → P2
Target Milestone: --- → 3.4
I think we should both change the rule and reference the .pl or .sh directly.

Changing the rule allows us to have .sh and .pl sources which are released as
commands in dist if we want.

Tools that are just meant to help with the build can keep the .sh and .pl and be
ran in place from the make file.

bob
Summary: Build fails for sep build dir owned by different user → Build failure when source is read-only: nfspwd
I will take this bug.
Assignee: relyea → wtc
Component: Libraries → Build
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Set target milestone to NSS 3.5.
Target Milestone: 3.4 → 3.5
Target Milestone: 3.5 → 3.7
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Remove target milestone of 3.8, since these bugs didn't get into that release.
Target Milestone: 3.8 → ---
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → build
could someone please get to this?
I fixed this bug in bug 311074, not remembering the existence
of this bug.

*** This bug has been marked as a duplicate of 311074 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → 3.11
You need to log in before you can comment on or make changes to this bug.