On 2014/10/12 16:45, Stefan Sitter wrote: > Thunderbird builds are currently busted because of compiler error in > mozilla/js/src/vm/ (Bug 1081523). Maybe retest once this problem is solved? >
Thank you for the info. (Yes, I noticed a quickly prepared patch sets are making round.) Will do, but I think I found something funny with configure process even before compilation is invoked: both for C-C TB and M-C FF. Looking at the logs of C-C TB compilation and M-C FF compilation at https://tbpl.mozilla.org/ and finding that there seem be intentions of using ccache, but not all the instances of configure invoked under various subdirectorioes are passed proper parameters (for invoking ccache during compilation, that is), I think this problem of not using ccache where it may be useful affects both C-C TB and M-C FF. (The situation of C-C TB configure breakage and M-C configure breakage from the viewpoint of ccache usage seems to differ slightly. I will investigate, but I suspect someone in the know can figure out the issues more quickly.) The breakage probably was introduced when build backend change took place (?). I believe people who manage compiler farms at mozilla foundation ought to look into this seriously. Maybe the compiler farms have experienced higher workload and longer wait time due to this issue. ccache could have lessened the workload, but was not used in some subdirectories. Of course, this affect local developer productivity as well. (I distinctively recall that jsmath.o takes a long time to produce and was happy that ccache makes the second compilation very fast. Due to configuration issues, sometimes I needed to clobber the object directory and start over, but I knew that I did not touch js-related source files already, and so ccache helped for the subsequent second compilation.) TIA On 2014/10/12 15:46, ISHIKAWA, Chiaki wrote:> I think this may no longer a TB-specific problem if > my hunch is correct. > > More at the end. > > On 2014/10/12 15:02, ISHIKAWA, Chiaki wrote: >> Hi, >> >> I am using ccache for local compilation of comm-central >> TB. >> >> After the checkout a few hours ago, and tinkering >> with my local hg patch queues, >> I noticed some files are NOT compiled using ccache any more. >> (I was debugging a local ccache that groks -gsplit-dwarf option >> to gcc. This option and use of GNU ld.gold makes linking rather fast.) >> >> I have not figured out which files are not compiled using ccache >> completely, but, as starters, >> the files under comm-central/mozilla/js/src/* >> such as jsobj.cpp and friends, >> and the files below such as comm-central/mozilla/js/src/vm/* >> such as CallNonGenericMethod.o and friends >> are compiled without using ccache :-( >> >> (I see the name of .o files printed out and I can link the >> final TB. So the build as a whole works: I use mk_add_options >> MOZ_MAKE_FLAGS="-s" to make the build log terse.) >> >> In the ccache log, compilation of these files mentioned above is not >> recorded at all. >> So presumably somehow the ccache is not invoked for these files. >> (But some files under mozilla/js/ subdirectories are compiled using >> ccache. See below.) >> >> My question is: >> Is this omission of ccache usage intentional for these files? >> >> In the following, I list files under mozilla/js directories >> which are still compiled using ccache (and thus the source file >> information was recorded in ccache log.) >> Th list is a sorted list in alphabetic order. >> Their order of compilation may differ. >> >> Note 1: >> I took out the common path prefix which is >> /REF-COMM-CENTRAL/comm-central which is my TOPSRCDIR directory and >> replaced it with ".". >> >> Note 2: >> But note that there is a strange path >> at the end, which is >> /REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/dom_quickstubs.cpp >> >> /REF-OBJ-DIR/objedir-tb3 is my MOZ_OBJ directory. >> So it looks that this dom-quickstubs.cpp is >> COPIED to MOZ_OBJ/js/xpconnect/src/ directory >> whereas other source files remain in the original source directory >> and some make hackery (VPATH maybe) makes the references to the original >> source files >> when the compilation proceed in MOZ_OBJ directory. >> >> E.g.: files under ./mozilla/js/ directory that are compiled using ccache >> [and recorded in ccache log]. >> "..." means that I omit the repetition of files under the same directory. >> >> ./mozilla/js/ductwork/debugger/JSDebugger.cpp >> ./mozilla/js/ipc/JavaScriptChild.cpp >> ./mozilla/js/ipc/JavaScriptParent.cpp >> ./mozilla/js/ipc/JavaScriptShared.cpp >> ./mozilla/js/ipc/WrapperAnswer.cpp >> ./mozilla/js/ipc/WrapperOwner.cpp >> ./mozilla/js/src/ctypes/libffi/src/closures.c >> ./mozilla/js/src/ctypes/libffi/src/debug.c >> ./mozilla/js/src/ctypes/libffi/src/java_raw_api.c >> ... >> ./mozilla/js/src/ctypes/libffi/src/x86/ffi64.c >> ./mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp >> ./mozilla/js/xpconnect/loader/mozJSLoaderUtils.cpp >> ./mozilla/js/xpconnect/loader/mozJSSubScriptLoader.cpp >> ./mozilla/js/xpconnect/shell/xpcshell.cpp >> ./mozilla/js/xpconnect/src/ExportHelpers.cpp >> ./mozilla/js/xpconnect/src/Sandbox.cpp >> ./mozilla/js/xpconnect/src/XPCCallContext.cpp >> ./mozilla/js/xpconnect/src/XPCComponents.cpp >> ./mozilla/js/xpconnect/src/XPCContext.cpp >> ... >> ./mozilla/js/xpconnect/src/XPCWrapper.cpp >> ./mozilla/js/xpconnect/src/nsScriptError.cpp >> ./mozilla/js/xpconnect/src/nsXPConnect.cpp >> ./mozilla/js/xpconnect/tests/components/native/xpctest_attributes.cpp >> ./mozilla/js/xpconnect/tests/components/native/xpctest_module.cpp >> ./mozilla/js/xpconnect/tests/components/native/xpctest_params.cpp >> ./mozilla/js/xpconnect/wrappers/AccessCheck.cpp >> ./mozilla/js/xpconnect/wrappers/AddonWrapper.cpp >> ./mozilla/js/xpconnect/wrappers/ChromeObjectWrapper.cpp >> ./mozilla/js/xpconnect/wrappers/FilteringWrapper.cpp >> ./mozilla/js/xpconnect/wrappers/WaiveXrayWrapper.cpp >> ./mozilla/js/xpconnect/wrappers/WrapperFactory.cpp >> . /mozilla/js/xpconnect/wrappers/XrayWrapper.cpp >> /REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/dom_quickstubs.cpp >> >> On a not so powerful PC at hand, not using ccache is >> a grave problem. >> I push and pop hg patch queues often and >> such qpush/qpop re-invokes the compilation of files of which mtime only >> are changed (the contents remain intact). >> ccache saves the day by not invoking the code generation path of the >> compilation. >> >> So, if there is no compelling reason for not using ccache for files under >> mozilla/js/ and its subdirectories (some directories use ccache as seen >> from above), I would like to see the ccache compilation restored. >> >> Yes, I think jsobj.cpp and friends were compiled using ccache before. >> But I don't know exactly when ccache became ineffective for these files. >> >> I would not have realized this problem unless I was hacking modified >> ccache to make sure it was working well. >> >> TIA >> >> PS: Despite I am using a local hacked version of ccache, I doubt if >> this is the cause of this problem. >> I have been using the series of locally hacked ccache versions, >> and it has performed well: I have been linking C-C TB for about a year >> and more successfully. >> >> PPS: Come to think of it, I am using Debian GNU/Linux, and >> I remember reading something about upcoming GNU Make >> changing behavior very slightly to conform to the latest POSIX standard >> in Debian's release note. >> That *may* explain the change in behavior. >> >> But someone familiar with the build process and/or >> mozilla/js source tree needs to take a look at to find out the root cause. >> > > OK, the following may be of relevant information. > > When mozilla/js/src is configured during automatic configure after > removing the > MOZ_OBJ directory, > I saw no mention of --with-ccache=/usr/bin/ccache on the command line > or > for that matter any mention of ccache in the command line. (Excerpt 1 > below). > I think that is why ccache is not used for the compilation of files > below this directory. > > On the other hand, when js/src/ctypes/libffi is configured > (and files below this directory were compiled using ccache), > I notice that the compiler command passed to configure as > variable (CC and CXX) has /usr/bin/ccache at its front and so > ccache is used. (Excerpt 2 below). > > Excerpt 1: Configuring js/src > Note the lack of "ccache" on the command line. > > [...] > configuring in js/src > running /bin/sh /REF-COMM-CENTRAL/comm-central/mozilla/js/src/configure > --enable-application=mail --enable-gc-zeal > --enable-debug-symbols=-gsplit-dwarf --disable-ldap --disable-necko-wifi > --enable-tests --disable-gstreamer --enable-debug --enable-shared > --enable-official-branding --enable-crashreporter > --disable-libjpeg-turbo --enable-default-toolkit=cairo-gtk2 > --with-system-ply --disable-necko-wifi --enable-valgrind > --enable-optimize=-g -O2 -freorder-blocks --disable-jemalloc > --disable-unified-compilation --enable-profiling > --with-external-source-dir=/REF-COMM-CENTRAL/comm-central > --enable-threadsafe --enable-ctypes --disable-shared-js > --disable-export-js --disable-gcgenerational > --with-nspr-cflags=-I/REF-OBJ-DIR/objdir-tb3/dist/include/nspr > --with-nspr-libs=-L/REF-OBJ-DIR/objdir-tb3/dist/lib -lnspr4 -lplc4 > -lplds4 --prefix=/REF-OBJ-DIR/objdir-tb3/dist > --cache-file=/REF-OBJ-DIR/objdir-tb3/config.cache > loading cache /REF-OBJ-DIR/objdir-tb3/config.cache > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking build system type... x86_64-unknown-linux-gnu > [...] > > > Excerpt 2: Configuring js/src/ctypes/libffi > Note that CC and CXX contains /usr/bin/ccache at the front. > (I think the printing could use quotes so that we would see > CC='...' CXX='...' instead of the value without quotes.) > BTW, I specify my CC as/usr/bin/gcc-4.9 and with the options: > -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 > -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 > when I configure the source directory. > That is why we have > CC=/usr/bin/ccache /usr/bin/gcc-4.9 -fno-builtin-strlen -Wl,--gdb-index > -Dfdatasync=fdatasync -DDEBUG=1 -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 > and ditto for CXX.) > > > [...] > configuring in js/src/ctypes/libffi > running /bin/sh > /REF-COMM-CENTRAL/comm-central/mozilla/js/src/ctypes/libffi/configure > --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu > --disable-shared --enable-static --disable-raw-api --enable-debug > --with-pic AS=$(CC) CC=/usr/bin/ccache /usr/bin/gcc-4.9 > -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 > -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 CXX=/usr/bin/ccache /usr/bin/g++-4.9 > -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 > -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 CPP=/usr/bin/gcc-4.9 > -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 > -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -E LD=ld AR=ar RANLIB=ranlib > STRIP=strip > --cache-file=/REF-OBJ-DIR/objdir-tb3/js/src/ctypes/libffi/config.cache > configure: creating cache > /REF-OBJ-DIR/objdir-tb3/js/src/ctypes/libffi/config.cache > checking build system type... x86_64-unknown-linux-gnu > > > So, I think it is a build system breakage somewhere. > > Why the difference between the subdirectories of js/src > are beyond me. > > I will file a bugzilla later, but I have no idea which subdirectories > are NOT passed proper ccache information during configure. > > So I will mention only this js/src directory and > ask someone in the know to figure the issues out. > > Has anyone compiling FF notice similar issues? > I think this would also affect FF developers. > > TIA > > > > _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
