231979 - Doesn't build from a read-only filesystem

Status: RESOLVED INACTIVE

(NSS :: Build, defect, P5)

Description

[Frédéric L. W. Meunier]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040123
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040123

I have the Mozilla sources in a Linux partition, along with my .mozconfig. I
mounted it read-only on FreeBSD, created a $HOME/tmp/objdir directory, and from
there issued a /mnt/src/CVS/X11/mozilla/configure.

Everything went well until I received the following error:

gmake[3]: Entering directory `/mnt/src/CVS/X11/mozilla/security/coreconf'
rm -rf     /usr/home/fredlwm/tmp/objdir/nss LOGS TAGS /usr/home/fredlwm/tmp/objd
ir/nss/.md core           so_locations _gen _jmc _jri _jni _stubs
rm: LOGS: Read-only file system
rm: TAGS: Read-only file system
rm: core: Read-only file system
rm: so_locations: Read-only file system
rm: _gen: Read-only file system
rm: _jmc: Read-only file system
rm: _jri: Read-only file system
rm: _jni: Read-only file system
rm: _stubs: Read-only file system
gmake[3]: *** [clean] Error 1
gmake[3]: Leaving directory `/mnt/src/CVS/X11/mozilla/security/coreconf'
gmake[2]: *** [.nss.cleaned] Error 2
gmake[2]: Leaving directory `/usr/home/fredlwm/tmp/objdir/security/manager'
gmake[1]: *** [tier_40] Error 2
gmake[1]: Leaving directory `/usr/home/fredlwm/tmp/objdir'
gmake: *** [default] Error 2

Then I was forced to mount the partition read-write, and the build went well.

I don't know if there are other places where it fails, as I mounted it
read-write for the rest of the build and have a minimal .mozconfig:

# sh
# Build configuration script
#
# See http://www.mozilla.org/build/unix.html for build instructions.
#


# Options for 'configure' (same as command-line options).
ac_add_options --prefix=/usr/X11R6/mozilla
ac_add_options --localstatedir=/var/lib
ac_add_options --with-pthreads
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-system-png
# ac_add_options --with-system-mng
ac_add_options --without-mng
ac_add_options --enable-default-toolkit=gtk2
# ac_add_options --disable-gtktest
ac_add_options --disable-mailnews
ac_add_options --disable-ldap
ac_add_options --disable-freetype2
# ac_add_options --disable-freetypetest
ac_add_options --enable-xft
# ac_add_options --disable-postscript
# ac_add_options --disable-xprint
ac_add_options --enable-crypto
ac_add_options --disable-jsd
# ac_add_options --disable-oji
ac_add_options --disable-accessibility
####ac_add_options --disable-xpfe-components
ac_add_options --disable-xpinstall
####ac_add_options --enable-single-profile
# ac_add_options --disable-jsloader
# ac_add_options --enable-native-uconv
ac_add_options --enable-plaintext-editor-only
ac_add_options --disable-composer
## default = cookie wallet content-packs xml-rpc xmlextras help p3p pref
## transformiix venkman inspector irc universalchardet typeaheadfind
## webservices spellcheck
## all = + xmlterm datetime finger cview layout-debug tasks
ac_add_options --enable-extensions=default,-venkman,-inspector,-irc,-spellcheck
## default = png gif jpeg bmp xbm
# ac_add_options --enable-image-decoders=
# ac_add_options --disable-mathml
ac_add_options --enable-svg
ac_add_options --disable-installer
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize='-O2 -march=athlon-xp -mfpmath=sse'
ac_add_options --disable-logging
ac_add_options --enable-reorder
ac_add_options --disable-logrefcnt
ac_add_options --disable-detect-webshell-leaks
ac_add_options --enable-strip
###ac_add_options --enable-elf-dynstr-gc
###ac_add_options --enable-old-abi-compat-wrappers
ac_add_options --enable-xterm-updates
ac_add_options --enable-default-mozilla-five-home=/usr/X11R6/mozilla
ac_add_options --disable-pedantic
ac_add_options --enable-cpp-rtti
ac_add_options --enable-cpp-exceptions
# ac_add_options --disable-libIDLtest
# ac_add_options --disable-glibtest
## ac_add_options --disable-xul
####ac_add_options --disable-profilesharing
## default = about data file ftp gopher http jar keyword res viewsource
# ac_add_options --enable-necko-protocols=
ac_add_options --disable-necko-disk-cache
# ac_add_options --enable-necko-small-buffers

export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
export MOZ_INTERNAL_LIBART_LGPL=1
export MOZ_MAKE_FLAGS=-j4
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
mk_add_options MOZ_INTERNAL_LIBART_LGPL=1
mk_add_options MOZ_MAKE_FLAGS=-j4


I also had to remove --enable-elf-dynstr-gc, but configure doesn't mention it's
only supported on Linux nor checks to see if it works. Correct me if I'm wrong.
I didn't log the errors, but there were references to Linux.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

NSS is it's own little puppy...  this probably belongs in the NSS product.

Comment 2

[cls]

It sounds like a bug in rm.  rm shouldn't complain when given the -f option if
the files are read-only.  Those files probably don't even exist unless you've
done a srcdir build with NSS previously.  Of course, NSS should be removing
those files from the objdir not the srcdir.

Comment 3

[Frédéric L. W. Meunier]

Testing with GNU coreutils 5.2.0 on Linux (FreeBSD doesn't use GNU rm, at least by default), I remounted my partition ro, and rm behaves like the other.

% rm -f /usr/local/src/CVS/X11/mozilla/aclocal.m4
rm: cannot remove `/usr/local/src/CVS/X11/mozilla/aclocal.m4': Read-only file system

% rm /usr/local/src/CVS/X11/mozilla/aclocal.m4
rm: remove regular file `/usr/local/src/CVS/X11/mozilla/aclocal.m4'? y
rm: cannot remove `/usr/local/src/CVS/X11/mozilla/aclocal.m4': Read-only file system

% rm /usr/local/src/CVS/X11/mozilla/aclocal.m4
rm: remove regular file `/usr/local/src/CVS/X11/mozilla/aclocal.m4'? n

Maybe Mozilla could just ignore such errors ? Sometimes I see errors being ignore by make, maybe because they don't harm.

But fixing rm isn't an option, as there are too many versions around, and also no guarantees that everyone will be using the latest and greatest.

And you're right. They don't exist in srcdir.

Maybe using something like $(OBJDIR) to LOGS and the others, so it removes them in objdir/security/coreconf and not srcdir/security/coreconf ?

$(OBJDIR) seems to be for objdir/nss . I don't know what would represent objdir/security/coreconf . Or are such files created in objdir/nss ? I can't test now.

Comment 4

[Frédéric L. W. Meunier]

Just to report that it worked with MOZILLA_1_7b_RELEASE on Linux using the same read-only partition. I won't be able to test on FreeBSD for at least a week, but if it still happens it may be a problem with their rm or ext2fs driver. Feel free to close it. If you don't, I'll add another comment as soon as I test it.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

NSS has its own build system (makefiles) that is supported by the NSS team.
mozilla has another build system (set of makefiles) that is NOT supported by
the NSS team, that is used instead of, or in addition to, NSS's makefiles,
to build NSS.  If there are problems in mozilla's build system for NSS, that
is a mozilla bug, not an NSS bug.  

NSS's build system does support builds from read-only file systems.  My guesses
about this bug report would be,

1. mozilla's build system doesn't invoke NSS's build system in the proper way
to build from a read-only source tree, in which case this is not an NSS bug, or

2. perhaps a regression now causes NSS's build system to no longer work 
properly when invoked properly to build from read-only sources, in which case
this IS an NSS bug.  

I don't recall at the moment what environment variables must be setup to build
NSS in a read-only source tree.  Bob, do you?

Comment 6

[Robert Relyea]

It appears the correct environment variable is being set. Doing a normal 'make
clean' in coreconf produces:

rm -rf      WINNT5.1_DBG.OBJ LOGS TAGS WINNT5.1_DBG.OBJ/vc20.pdb WINNT5.1_DBG.OB
J/vc40.pdb WINNT5.1_DBG.OBJ/.md core           so_locations _gen _jmc _jri _jni
_stubs


I think the build was depending on the -f flag to ignore the error. None of the
files that aren't prefaced with the $(OBJDIR) are needed by the NSS builds (tags
are a separat target, LOGS and core are not part of any build, per se, and _*
are part of the JSS build (which probably doesn't build in a RO file sytem).

I suspect the best fix is to force the make system to ignore the error.

bob

Comment 7

[Bruce Robson]

I've also been unable to build from a read only filesystem.

I dual boot between Microsoft Windows 2000 and Linux. I have 3 partitions. My first partition is a NTFS partition that holds Windows 2000, my second partition is a Linux Swap partition and my third partition is an ext2 partition that holds Linux.

I have the Mozilla source files on the NTFS partition. I have successfully built Mozilla under Windows 2000 using an object directory outside the mozilla source tree. This has left files .mozconfig.mk and .mozconfig.out in the top directory of the Mozilla source tree.

I've now booted to Linux and mounted the NTFS partition (read only as Linux doesn't support read/write of NTFS) on /mnt/hda1. I have a .mozconfig file in my Linux home directory that specifies an object directory on the ext2 partition.

I try a build and get the following

/mnt/hda1/files/mozilla$ make -f client.mk build
/bin/sh: line 1: mozilla/.mozconfig.out: Read-only file system
Adding client.mk options from /cygdrive/c/files/Bruce/.mozconfig:
    MOZ_OBJDIR=/cygdrive/c/files/Bruce/moz_objdir
    MOZ_CO_PROJECT=suite
rm: cannot remove `.mozconfig.out': Read-only file system
make: *** [build] Error 1
/mnt/hda1/files/mozilla$

The three lines 
    Adding client.mk options from /cygdrive/c/files/Bruce/.mozconfig:
        MOZ_OBJDIR=/cygdrive/c/files/Bruce/moz_objdir
        MOZ_CO_PROJECT=suite
are the contents of the .mozconfig.out file left from building under Windows 2000.

My mozilla source tree is from MOZILLA_1_7_BRANCH

Comment 8

[timeless]

Attachment: draft

could someone test this? :)

and would someone please confirm this bug? clearly we've established that the coreconf system was invoked, and that it used rm and that the rm on certain bsd's sucks.

re Comment #7. Bruce Robson: your problem is unrelated. mozilla does in fact use two files in the root of the mozilla directory structure, because until it's used those files, it doesn't know where it should live, you can work around this by doing:

mkdir -p /tmp/symlink-maze/mozilla
cd /tmp/symlink-maze/mozilla
ln -s /mnt/hda1/files/mozilla/* /mnt/hda1/files/mozilla/.* .
rm .mozconfig.out
make -f client.mk build

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Please re-read my comment 5.  again.

NSS's coreconf build system uses an environment variable named BUILD_TREE
for building from read-only sources.  The build is assumed to be taking place 
in a directory (".") in a writable file system (the binaries have to be 
written SOMEWHERE), but the sources may be coming from a different file 
system as specified by BUILD_TREE.

In that mode, it is OK for the script to issue rm commands that operate on 
the directoy in the writable file system (as it does).  

Bob implemented the BUILD_TREE stuff in coreconf in April 2001, which is 
why I asked him in comment 5 to comment on it.  I think Bob knows how that
feature is supposed to work.  Bob's comment 6 said "It appears the correct 
environment variable is being set." but he didn't name that variable 
(BUILD_TREE) and I've not yet seen any evidence that BUILD_TREE was being 
used.  So, before we "confirm" this bug, I want to see evidence that it 
doesn't work when BUILD_TREE is properly used.  

If BUILD_TREE no longer works when properly configured, as it once did, 
that's a regression (IMO).  

Comment 10

[timeless]

http://landfill.mozilla.org/mxr-test/seamonkey/search?string=BUILD_TREE&find=Makefile&filter=

These files were searched.
Found one matching line
BUILD_TREE
/security/manager/Makefile.in, line 154 -- DEFAULT_GMAKE_FLAGS += BUILD_TREE=$(MOZ_BUILD_ROOT)

Based on my quick reading of the makefile, i'm pretty sure we'd use that whenever we use an objdir

from:
rm -rf     /usr/home/fredlwm/tmp/objdir/nss LOGS TAGS

it sure looks like the rm is not properly prefixing objdir paths

http://landfill.mozilla.org/mxr-test/seamonkey/search?string=LOGS&find=coreconf 

These files were searched.
Found one matching line
LOGS
/security/coreconf/ruleset.mk, line 177 -- ALL_TRASH = $(TARGETS) $(OBJS) $(OBJDIR) LOGS TAGS $(GARBAGE) \


 177 ALL_TRASH =     $(TARGETS) $(OBJS) $(OBJDIR) LOGS TAGS $(GARBAGE) \
 178                 $(NOSUCHFILE) $(JDK_HEADER_CFILES) $(JDK_STUB_CFILES) \
 179                 $(JRI_HEADER_CFILES) $(JRI_STUB_CFILES) $(JNI_HEADERS) \
 180                 $(JMC_STUBS) $(JMC_HEADERS) $(JMC_EXPORT_FILES) \
 181                 so_locations _gen _jmc _jri _jni _stubs \
 182                 $(wildcard $(JAVA_DESTPATH)/$(PACKAGE)/*.class) \
 183                 $(BUILT_SRCS)

It definitely doesn't prefix LOGS or TAGS with OBJDIR.