Description
cmuelle8
2013-03-21 17:47:19 UTC
Created attachment 342858 [details, diff]
patches (elfhack, debug flags, mssse3 detection issue)
you might not need to patch out mssse3 detection if you're on a host that supports it
- this is for an "-O2 -flto" build with clang, elfhack enabled 39528 /usr/lib64/firefox/libxul.so 8476 /usr/lib64/firefox/omni.ja 316 /usr/lib64 232 /usr/bin 84 /usr/lib64/firefox/webapprt-stub 80 /usr/lib64/firefox/mozilla-xremote-client 76 /usr/lib64/firefox/firefox 76 /usr/lib64/firefox/firefox-bin -> segfaults in libxul.so while running as well (dromaeo.com to test) - reference size for a usual "-O2" build with gcc, elfhack enabled 36560 /usr/lib64/firefox/libxul.so 8476 /usr/lib64/firefox/omni.ja 316 /usr/lib64 232 /usr/bin 128 /usr/lib64/firefox/webapprt-stub 104 /usr/lib64/firefox/firefox 104 /usr/lib64/firefox/firefox-bin -> works fine - this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled 34548 /usr/lib64/firefox/libxul.so 8476 /usr/lib64/firefox/omni.ja 316 /usr/lib64 232 /usr/bin 120 /usr/lib64/firefox/webapprt-stub 96 /usr/lib64/firefox/firefox 96 /usr/lib64/firefox/firefox-bin -> segfaults in libxul.so while dromaeo.com loads (like all other builds with clang so far) - for completeness, these were the base flags used in /etc/paludis/bashrc for all compiles, with varying O*/-flto variations to CFLAGS as noted for the individual cases above, and the addition of -Wl,-z,norelro to LDFLAGS when clang was used CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=native -pipe -O2" LDFLAGS="-Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common" MAKEOPTS="-j1" So far the only stable firefox-compile in my short test series was the "usual" one with gcc (-O2, elfhack enabled, lto disabled). The comparison is biased, since gcc-4.7.2 is a stable release and the clang/llvm I used were live versions from svn trunk. The tests done so far, in chronological order, first field shows libxul size: [40.304] [unstable] clang-9999 -O4 [46.132] [unstable] clang-9999 -O4 (--disable-elf-hack) [39.528] [unstable] clang-9999 -O2 -flto [36.560] [ stable] gcc-4.7.2 -O2 [34.548] [unstable] clang-9999 -O2 Greetings Created attachment 342926 [details]
paludis/cave build log of firefox build using gcc-4.7.2 -O2 -flto
The test series omits results for an gcc "-O2 -flto" build. Trying this, compilation interrupted with an error linking jsheaptools, see attachment for full build log. Excerpt:
x86_64-pc-linux-gnu-g++ -o jsheaptools.o -c -I../../../dist/system_wrappers_js -include /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/config/gcc_hidden.h -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -I/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src -I.. -I/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/shell -I. -I../../../dist/include -I/usr/include/nspr -fPIC -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=native -pipe -mfpmath=sse -flto=4 -floop-block -floop-interchange -floop-strip-mine -fuse-linker-plugin -mno-avx -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF .deps/jsheaptools.o.pp /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/shell/jsheaptools.cpp
/usr/bin/python2.7 /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/config/pythonpath.py -I../config /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/config/expandlibs_exec.py --depend .deps/js.pp --target js --uselist -- x86_64-pc-linux-gnu-g++ -o js -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=native -pipe -mfpmath=sse -flto=4 -floop-block -floop-interchange -floop-strip-mine -fuse-linker-plugin -mno-avx -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer js.o jsoptparse.o jsheaptools.o -lpthread -march=native -pipe -mfpmath=sse -flto=4 -floop-block -floop-interchange -floop-strip-mine -fuse-linker-plugin -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,--icf=safe -Wl,-rpath-link,../../../dist/bin -Wl,-rpath-link,/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/lib -L../../../dist/bin -L../../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a ../libjs_static.a -lz -Wl,--whole-archive ../../../dist/lib/libmozglue.a ../../../dist/lib/libmemory.a -Wl,--no-whole-archive -rdynamic -ldl -lffi
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x36): error: undefined reference to 'PushActiveVMFrame'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x49): error: undefined reference to 'PopActiveVMFrame'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x68): error: undefined reference to 'js_InternalThrow'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x77): error: undefined reference to 'PopActiveVMFrame'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0x95): error: undefined reference to 'js_InternalInterpret'
/var/tmp/paludis/www-client-firefox-19.0.2/temp//ccg5er9g.ltrans0.ltrans.o(.text+0xbc): error: undefined reference to 'PopActiveVMFrame'
collect2: error: ld returned 1 exit status
make[6]: *** [js] Error 1make[6]: Leaving directory `/var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/obj-x86_64-unknown-linux-gnu/js/src/shell'
(In reply to comment #3) > - this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled > > 34548 /usr/lib64/firefox/libxul.so > [...] > [40.304] [unstable] clang-9999 -O4 > [46.132] [unstable] clang-9999 -O4 (--disable-elf-hack) > [39.528] [unstable] clang-9999 -O2 -flto > [36.560] [ stable] gcc-4.7.2 -O2 > [34.548] [unstable] clang-9999 -O2 Accidentaly I found out that using firefox -safe-mode makes the clang compiles stable - dromaeo.com tests finish without segfaulting. I then thought that some extensions in my profile might have caused the segfaulting behavior, so the profile was backuped and rm -rf ~/.mozilla was called to have FF create a fresh profile on start. However, even with a fresh profile created (no extensions in effect), dromaeo.com makes clang-FF segfault. I noticed that -safe-mode also sets the locale to en, so I gave firefox -UIlocale en a try, presuming that maybe just the de locale was an issue. It was not, FF reproducably segfaulted. The only chance of completing dromaeo.com tests with the [unstable]-marked FF builds above, was to use firefox -safe-mode -safe-mode Disables extensions and themes for this session. The description of this option does not seem to be exhaustive. A fresh profile, with neither extensions or themes installed, segfaults as well, so this cannot be the same as using -safe-mode. Presumably there are other things turned off internally if this option is in effect. This might help to narrow down why clang-FF segfaults without it. Greetings (In reply to comment #5) > (In reply to comment #3) > > - this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled > > > Presumably there are other > things turned off internally if this option is in effect. This might help > to narrow down why clang-FF segfaults without it. There is a more comprehensive set of what is turned off here: http://kb.mozillazine.org/Safe_mode "JIT JS compiler" is disabled in safe-mode, so a good guess is that the clang builds segfault somewhere in the JIT code of FF. If jit-js may be compiled and tested stand-alone, this might reduce the problem. Compiling only that part of the source with gcc might help drill down to the clang-offending source file. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > - this is for an "-O2" build with clang-9999, elfhack enabled, lto disabled > > This might help to narrow down why clang-FF segfaults without it. > http://kb.mozillazine.org/Safe_mode > "JIT JS compiler" is disabled in safe-mode - this is a stacktrace for an "-g -O2" build with clang-9999, elfhack enabled, lto disabled Program received signal SIGSEGV, Segmentation fault. JS::CallReceiver::callee (this=0x7fffffff8790) at ../../../dist/include/jsapi.h:1384 1384 ../../../dist/include/jsapi.h: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 JS::CallReceiver::callee (this=0x7fffffff8790) at ../../../dist/include/jsapi.h:1384 #1 0x00007ffff60e829c in js::ContextStack::getFixupFrame (this=0x7fffd020c598, cx=0x7fffd020c4f0, report=js::DONT_REPORT_ERROR, args=..., fun=0x7fffcf5fab80, script=0x7fffcf5f5640, ncode=0x7fffffff8790, initial=(unknown: 718596888), stackLimit=0x7ffff7e6db70) at /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/vm/Stack-inl.h:498 #2 0x00007ffff60e80e6 in js::mjit::stubs::FixupArity (f=..., nactual=4158481088) at /var/tmp/paludis/www-client-firefox-19.0.2/work/mozilla-release/js/src/methodjit/InvokeHelpers.cpp:212 #3 0x00007fffd9a38c03 in ?? () #4 0x00007fffd9a39b4d in ?? () #5 0x0000000000000000 in ?? () (gdb) quit Any ideas? Using about:config to set javascript.options.methodjit.chrome;false javascript.options.methodjit.content;false helps, so the problem definitely seems to be in methodjit. Atm methodjit can be turned off directly in the FF ebuild. Another thing I noticed is mozilla-release/config.guess and mozilla-release/js/src/config.guess might produce wrong results wrt to the Gentoo ebuild. The ebuild sets TARGET and BUILD to the CHOST of make.conf, respectively paludis/bashrc. This is a problem, since the configure toolchain of FF detects crosscompilation via test TARGET != HOST. E.g. if you have CHOST=x86_64-pc-linux-gnu set in your make.conf or bashrc this will conflict with the output of mozilla-release/build/autoconf/config.guess and mozilla-release/js/src/build/autoconf/config.guess which for the example host would be CHOST=x86_64-unknown-linux-gnu The ebuild uses CHOST as an option to --target and --build, but not --host. The configure happens twice, i.e. js/src/configure is called from within configure in the top level directory, so when "cross-compilation" is wrongly detected in js/src/configure, because of x86_64-unknown-linux-gnu != x86_64-pc-linux-gnu the CC and CXX are determined differently than for the calling configure. One ends up compiling the top level dir with "clang", and js/src with "gcc" because this is the first matching default js/src/configure tests against. There are two ways to solve this - either leave out or adjust -target and -build in the /ebuild/ to match the output of mozilla-release/config.guess or let the ebuild (eventually euser_)patch mozilla-release/client.mk --- mozilla-release/client.mk 2013-03-07 11:48:37.000000000 +0100 +++ mozilla-release/client.mk.new 2013-03-24 00:07:26.531818896 +0100 @@ -75,6 +75,9 @@ CONFIG_GUESS_SCRIPT := $(wildcard $(TOPSRCDIR)/build/autoconf/config.guess) ifdef CONFIG_GUESS_SCRIPT + # these need to be in sync, so change them in sync + CONFIG_GUESS := $(shell echo -e "\#!/bin/sh\necho $${CHOST}" > $(CONFIG_GUESS_SCRIPT)) + CONFIG_GUESS := $(shell echo -e "\#!/bin/sh\necho $${CHOST}" > $(subst build,js/src/build,$(CONFIG_GUESS_SCRIPT))) CONFIG_GUESS := $(shell $(CONFIG_GUESS_SCRIPT)) endif On x86 this bug does not surface, since config.guess produces *-pc-* for i*86 hosts afa i've seen. Using this patch one can be sure that the mozilla toolchain does not accidentaly detect cross-compilation. Btw, this false detection happens with CC=gcc as well, but it's less a problem, since the default HOST_CC picked in js/src when cross-compiling is again gcc, but this is not, as should be, determined by the ENVironment passed. The patch irons out this problem on x86_64 and theoretically should on all other archs as well, as echoing CHOST from config.guess harmonizes with the values given in the ebuild. The environment of CC CXX vars carefully set up in mozialla-release/configure is used in js/src if cross-compilation is not detected, this is how it's intended if you're not indeed cross-compiling.. Greetings Created attachment 343108 [details, diff] firefox-19.0.2-clang-and-config.guess.patch patches elfhack, debug flags, mssse3 detection issue, config.guess to compile with clang (update, includes the patch listed in comment #8 files effected: mozilla-release/build/unix/elfhack/Makefile.in mozilla-release/js/src/configure.in mozilla-release/configure.in mozilla-release/client.mk mozilla-release/build/autoconf/config.guess mozilla-release/js/src/build/autoconf/config.guess Created attachment 343112 [details, diff]
firefox-19.0.2.ebuild.patch
patch ebuild to
- account for know jit segfault/bug (--disable-methodjit)
- enable-address-sanitizer
- enable-llvm-hacks
- not modify some flags (-mno-avx, -fno-stack-protector) that are set depending on gcc-version
(if clang is used)
- keep prior behavior
(if clang is not used)
- respect EXTRA_ECONF (harmonize with other ebuilds), so gentoo users may use EXTRA_ECONF to pass options to the FF configure's
(for all compilers)
Greetings
(In reply to comment #4) > Created attachment 342926 [details] > paludis/cave build log of firefox build using gcc-4.7.2 -O2 -flto > > The test series omits results for an gcc "-O2 -flto" build. Trying this, > compilation interrupted with an error linking jsheaptools, see attachment > for full build log. There is a metabug for this problem here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 with minimum patches to gcc needed here http://gcc.gnu.org/bugzilla/attachment.cgi?id=23364 So this is not a FF issue, a successful LTO build will depend on a gcc containing these patches, i.e. >sys-devel/gcc-4.7.2-r1 with a minimum gcc version yet to be found. For the scope of FF compile on gentoo it probably makes sense to defer searching this route until the depends of this metabug are closed.. Applying the attached patches, an imho most promising, debugging issue to get a more performant FF on Gentoo/amd64 remains: How to iron out FF segfaults if --enable-methodjit is used with clang? So far, neither --enable-llvm-hacks nor both --enable-address-sanitizer --enable-llvm-hacks seem to influence this bug. Any ideas? (In reply to comment #12) > How to iron out FF segfaults if --enable-methodjit is used with clang? "And now for sth completely different.." It turns out that there is a way to enable a stable jit with clang compiles. With the current patch, if clang is used, I feed --disable-methodjit --enable-tracejit to .mozconfig which compiles and runs fine, but apparently does not use tracejit or any js jit at all, as it leads to a mediocre ~68 runs/s on 3D-Mesh dromaeo.com test Comparing this to the non-LTO -O2 gcc build referenced above which resulted in ~1438 runs/s on 3D-Mesh dromaeo.com test leads to the presumption that tracejit probably depends on methodjit to function, so presumably we cannot disable it, if we want jit to work. For tests I went back to feed both --enable-methodjit --enable-tracejit to clang compiles, which reproducably returned the segfaults described above. So, in about:config I set javascript.options.methodjit.content;false javascript.options.methodjit.chrome;false (for --enable-methodjit compiles these are turned on by default in mozilla-release/modules/libpref/src/init/all.js) Having done this, I redid js-tests on my LTO -O4 clang build, resulting in a whopping ~1530 runs/s on 3D-Mesh dromaeo.com test How is that? My explanation for this strange behavior currently is, that tracejit is used at _run time_ if methodjit is turned off in "about-config". However, at _compile time_ methodjit needs to be enabled, else all of jit, including tracejit, is dead code ot not even compiled in. May someone please confirm this on another box? Also, writing this using the current clang -O4 build, I notice sluggish UI behavior. E.g. the menus switch a little slower than in gcc build, so I guess it's not a full success story yet. However, it's getting there.. In conclusion, if you want to confirm the dromaeo.com results, do - apply the two patches, follow along comment #1 - edit the patched ebuild, replace "disable-methodjit" by "enable-methodjit" - do a clang build - run firefox and set javascript.options.methodjit.content;false javascript.options.methodjit.chrome;false - run dromaeo.com tests If the UI things are solved this turns out to be a viable alternative to a gcc build, as we can easily change the methodjit defaults in mozilla-release/modules/libpref/src/init/all.js by adding the change to the user patch attached. Greetings (In reply to comment #13) > the current clang -O4 build, I notice sluggish UI behavior. E.g. the menus > switch a little slower than in gcc build, update: This must have been subjective, cross-checking with a gcc build after that did not show any difference. Might have had to do with a cairo rebuild in between, but it's definitely not FF related or worth searching for.. So the only insight not yet included in the attached patches is the methodjit curiosity, somebody please confirm this. Thanks (In reply to comment #13) > How is that? My explanation for this strange behavior currently is, that > tracejit is used at _run time_ if methodjit is turned off in "about-config". [...] > May someone please confirm this on another box? Meanwhile I was able to produce a clang (from trunk) build using -O2 on an i686-pc-linux-gnu box running on atom n270, see https://bugzilla.mozilla.org/show_bug.cgi?id=854936 The build does not segfault like on x86_64-pc-linux-gnu, i.e. it's not necessary to turn of methodjit in about:config. dromaeo.com results are decent for an atom, I guess http://dromaeo.com/?id=192620 I suppose it's an arch dependent problem.. Hi all. I'm also not able to build firefox-19.0.2 here on my i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz with 1GB RAM and 4GB swap. Have been built/installed version 19.0 fine since 24.02.2013 instead. No LTO config on this box, here some more details, please tell if you need more here, or should I open a new different report for this: * Running elibtoolize in: mozilla-release/modules/freetype2/builds/unix/ ...skipping... >, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' was declared here i686-pc-linux-gnu-g++ -o Stack.o -c -I./../../dist/system_wrappers_js -include /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/config/gcc_hidden.h -DENABLE_TYPEDARRAY_MOVE -DENABLE_YARR_JIT=1 -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".so\" -DUSE_ZLIB -I/usr/lib/libffi-3.0.13/include -I. -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/../../mfbt/double-conversion -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src -I. -I./../../dist/include -I/usr/include/nspr -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/assembler -I/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/yarr -fPIC -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=atom -pipe -mno-avx -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe -DNDEBUG -DTRIMMED -g -O2 -fomit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -DENABLE_JIT=1 -DMOZILLA_CLIENT -include ./js-confdefs.h -MD -MF .deps/Stack.o.pp /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Stack.cpp String.cpp In file included from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jsatom.h:22:0, from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jscntxt.h:21, from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.h:15, from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:8: /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/gc/Barrier.h: In static member function 'static bool js::Debugger::slowPathOnLeaveFrame(JSContext*, bool)': /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/gc/Barrier.h:173:34: warning: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' may be used uninitialized in this function [-Wmaybe-uninitialized] /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:576:21: note: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' was declared here In file included from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jsatom.h:22:0, from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/jscntxt.h:21, from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.h:15, from /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:8: /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/gc/Barrier.h:173:34: warning: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' may be used uninitialized in this function [-Wmaybe-uninitialized] /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Debugger.cpp:525:21: note: '*((void*)(& r)+16).js::detail::HashTable<js::HashMapEntry<js::StackFrame*, js::RelocatablePtr<JSObject> >, js::HashMap<js::StackFrame*, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::StackFrame*>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::Ptr::entry' was declared here /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Stack.cpp: In member function 'js::StackIter& js::StackIter::operator++()': /var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/js/src/vm/Stack.cpp:1541:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. {standard input}: Assembler messages: {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive make[5]: *** [Stack.o] Error 1 make[5]: *** Waiting for unfinished jobs.... make[5]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu/js/src' make[4]: *** [libs_tier_js] Error 2 make[4]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu' make[3]: *** [tier_js] Error 2 make[3]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu' make[2]: *** [default] Error 2 make[2]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release/obj-i686-pc-linux-gnu' make[1]: *** [realbuild] Error 2 make[1]: Leaving directory `/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release' make: *** [build] Error 2 emake failed * ERROR: www-client/firefox-19.0.2 failed (compile phase): * emake failed * * Call stack: * ebuild.sh, line 93: Called src_compile * environment, line 4882: Called die * The specific snippet of code: * CC="$(tc-getCC)" CXX="$(tc-getCXX)" LD="$(tc-getLD)" MOZ_MAKE_FLAGS="${MAKEOPTS}" emake -f client.mk || die "emake failed"; * * If you need support, post the output of `emerge --info '=www-client/firefox-19.0.2'`, * the complete build log and the output of `emerge -pqv '=www-client/firefox-19.0.2'`. * The complete build log is located at '/var/tmp/portage/www-client/firefox-19.0.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/www-client/firefox-19.0.2/temp/environment'. * Working directory: '/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release' * S: '/var/tmp/portage/www-client/firefox-19.0.2/work/mozilla-release _________________________________________________________________________ emerge --info =www-client/firefox-19.0.2 Portage 2.2.0_alpha169 (default/linux/x86/13.0/desktop/kde, gcc-4.7.2, glibc-2.16.0, 3.7.10-gentoo i686) ================================================================= System Settings ================================================================= System uname: Linux-3.7.10-gentoo-i686-Intel-R-_Atom-TM-_CPU_N270_@_1.60GHz-with-gentoo-2.2 KiB Mem: 1020168 total, 729436 free KiB Swap: 4094972 total, 4094972 free Timestamp of tree: Wed, 27 Mar 2013 17:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.10.2-r1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.11.6, 1.13.1 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.2-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.8 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo Installed sets: @system ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=atom -O2 -fomit-frame-pointer -pipe -mfpmath=sse" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=atom -O2 -fomit-frame-pointer -pipe -mfpmath=sse" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet-build=n --keep-going --autounmask-write" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://gentoo.tiscali.nl/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" LANG="de_DE.UTF-8" LC_ALL="" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="7Zip X a52 aac aalib acl acpi akonadi alsa apng asf audiofile bash-completion berkdb branding bzip2 cairo cdda cdr cjk cli consolekit cracklib crypt css cups cxx dbus declarative dga dhcpcd djvu dlloader dri drm dts dv dvd dvdr dvdread dvi emboss enca encode exif extras fame fat ffmpeg fftw firefox firefox3 flac flash fontconfig fortran ftp g3dvl gallium gbm gdbm gif git gles gles1 gles2 glib gphoto2 gpm graphviz gs gstreamer gtk iconv icq imap intel ipv6 irc jabber java jpeg kde kexiv2 kipi kpathsea lame laptop lcms ldap lensfun libcaca libclamav libnotify libsamplerate libv4l libv4l2 liemikuutio lirc live llvm lm_sensors lzma lzo mad mainmenuhooks matroska metric minizip mjpeg mmx mng modemmanager modules mp3 mp4 mpeg mplayer msn mudflap musepack mysql nas ncurses network networkmanager nfsv4 nfsv41 nls nptl nsplugin nss ntfs ntp ogg ogm okular openal opengl openmp openssl openstreetmap openvg optimization opus osdmenu osmesa pam pango parted pastebin pcm pcre pdf pdfimport phonon plasma player plugin pm-utils pmu png pnm policykit pop postproc ppds ppp prison privacy python python3 qalculate qt qt3support qt4 quicktime rar raw readline recode recording redeyes rle rss rtmp rtsp scanner schroedinger script sdk sdl sdl-image sdl-sound secure-delete semantic-desktop server session sftp shine shorten shout sift skype smp sms sna sndfile soundextract speech speex spell sql sse sse2 ssl ssse3 startup-notification stk stream strigi svg syncearly tcpd templates tga theora threads thumbnail tiff toolame tools transcode tremor truetype twolame udev udisks umfpack unicode upower urlpicpreview usb utils v4l v4l2 vaapi vamp vcd vcdinfo vcdx video virtuoso vlm vorbis vpx vxml wav wavpack webcam webdav webkit webpresence win32codecs winbind windeco wma wma-fixed wmf wxwidgets x264 x86 xanim xcb xcomposite xine xinerama xml xorgmodule xpm xprint xscreensaver xsl xslt xv xvid xvmc xwax_decoders_aac xwax_decoders_cd xwax_decoders_flac xwax_decoders_misc xwax_decoders_mp3 xwax_decoders_ogg yaepg yahoo youtube yv12 zip zlib" ABI_X86="32" ALSA_CARDS="hda-intel loopback virmidi" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="*" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de" LIRC_DEVICES="devinput" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="intel i915" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON (In reply to comment #16) > Hi all. > > I'm also not able to build firefox-19.0.2 here on my i686 Intel(R) Atom(TM) > CPU N270 @ 1.60GHz with 1GB RAM and 4GB swap. > Have been built/installed version 19.0 fine since 24.02.2013 instead. > Thanks for reporting, you most probably hit bug #461694 - it's an optimization bug in gcc-4.7.2-r1 with regard to atom arch. It's well debuged thanks to one of the toolchain maintainers and might be fixed in next gcc version. Reportedly using gcc-4.6.3 is ok, but I did not try that myself. This bug is (mainly) about compiling FF with clang - you're using gcc, so either open a new bug if you think you have a different issue or append to bug #461694 if you've additional information. As for this bug I'm looking for someone who can confirm that /not/ disabling methodjit makes the clang compile segfault, while turning methodjit off in about:config of that same segfaulting build makes it work. Greetings (In reply to comment #17) > As for this bug I'm looking for someone who can confirm that /not/ disabling > methodjit makes the clang compile segfault, while turning methodjit off in > about:config of that same segfaulting build makes it work. Please read comment #13 if you want to help with this - you probably need an x86_64 arch, since I crossed check on x86 which does not show the same behavior. Thanks Thanks for your fast respond and sorry for my delayed answer. It takes lot of time to build the already deleted gcc-4.6.3 again on my atom pc and than to recompile firefox to give a positive statement, but I will do so in your referenced report. Regarding your call for testing and #13. I won't try that on my x86_64 Box, cause I'm not using clang. Created attachment 343798 [details] firefox-19.0.2.ebuild.patch Update ebuild patch based on gathered knowledge - correct usage of address-sanitizer - patch methodjit in run-time options to false, only on x86_64 See https://developer.mozilla.org/en-US/docs/Building_Firefox_with_Address_Sanitizer#Adjusting_the_build_configuration https://bugzilla.mozilla.org/show_bug.cgi?id=854936 for details. Created attachment 343800 [details, diff]
firefox-19.0.2.ebuild.patch
retab patch (fix messed up whitespace..)
Created attachment 344010 [details, diff] /etc/portage/patches/www-client/firefox-19.0.2/firefox-19.0.2-clang-3.3svn.patch Newest clang from trunk seems to have stricter namespace checking. Adding the following namespace prefixes was required to get a clean compile with clang from trunk. The patch reflects those changes. - sp->init(comp, this->asObjectPtr(), offset++, UndefinedValue()); + sp->init(comp, this->asObjectPtr(), offset++, JS::UndefinedValue()); - sp->init(comp, this->asObjectPtr(), offset++, UndefinedValue()); + sp->init(comp, this->asObjectPtr(), offset++, JS::UndefinedValue()); - AutoAssertNoGC nogc; + JS::AutoAssertNoGC nogc; Also moved out config.guess patch, it's now in bug #462488 Up to now, using the patches from that and this bug, I was able to produce and stably run builds on x86 and x86_64. Created attachment 344638 [details, diff]
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.3svn.patch
For the transition from FF 19.0.2 to FF 20.0 a small addition was appended to the previous patch regarding file
mozilla-release/js/src/jspropertycacheinlines.h
@@ -64,7 +64,7 @@
js::PropertyCache::testForSet(JSContext *cx, jsbytecode *pc, JSObject *obj,
PropertyCacheEntry **entryp, JSObject **obj2p, PropertyName **namep)
{
- AutoAssertNoGC nogc;
+ JS::AutoAssertNoGC nogc;
JS_ASSERT(this == &cx->propertyCache());
Created attachment 344640 [details, diff]
firefox-20.0.1.ebuild.patch
Comment on attachment 344638 [details, diff]
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.3svn.patch
update to new rev - renaming sufficed, codebase wrt patch unchanged
Created attachment 351352 [details, diff]
firefox-21.0.ebuild.patch
ion seems to have the same problem as methodjit when compiled with clang - segfaults FF unless disabled
remaining changes to a large extent identical to the ones for 20.0.1
Created attachment 351766 [details, diff]
firefox-21.0.ebuild.patch
fix js headers patch that did not apply correctly since 21.0
Created attachment 351768 [details, diff]
/etc/portage/patches/www-client/firefox-21.0/firefox-21.0-clang-3.4svn.patch
All you experimental changes with clang and using -9999 is not gonna be supported by gentoo developers. You can file bugs with upstream if you would like things fixed. You're funny. Upstream uses clang builds since long, it's just the gentoo ebuilds/eclasses that do not support it. Also as a mozilla maintainer you should know that upstream does not fix released versions, you can be happy if some dev fishes out your bug there to fix in trunk. Since the changeset more or less survived four different versions now, it is pretty robust to incorporate, it's also needed for clang 3.3 now in tree as testing. but where there is no will, there's no way. you've made your point. just leave it open for other experimental natures seeking help. if you ever feel different about it, my offer maintaining these changes until they're fully obsoleted by a release in the future still stands. take care. (In reply to cmuelle8 from comment #30) > You're funny. Upstream uses clang builds since long, it's just the gentoo > ebuilds/eclasses that do not support it. Also as a mozilla maintainer you > should know that upstream does not fix released versions, you can be happy > if some dev fishes out your bug there to fix in trunk. > If upstream accepts the patches and integrates them into HEAD, then we do maintain them via backporting. I'm sure if you can push to get the clang changes you want into the mozilla build system (ie attachment 351768 [details, diff]) via upstream, then official gentoo support is much more likely. Created attachment 352652 [details, diff]
/etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.x.patch
- patching jspropertycacheinlines.h is not necessary with FF 22.0, patch reduced
- moving mssse3 detection and the debug flag logic still not fixed in trunk
- ion and methodjit still disabled with clang by default - please enable and test stability using about:config in FF's address bar - report back if you spare some time
Created attachment 352654 [details, diff]
firefox-22.0.ebuild.patch
patch against stock ebuild in tree
(In reply to cmuelle8 from comment #33) > Created attachment 352654 [details, diff] [details, diff] > firefox-22.0.ebuild.patch > > patch against stock ebuild in tree While I had some issues compiling FF 21.0 with clang on gentoo unsolved by the supplied patches, 22.0 compiles and runs fine again. So the following issue is gone and solved in 22.0. =========[PROBLEM-LOG of 21.0, SOLVED in 22.0] [...] In file included from /var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:20: ./../../dist/include/mozilla/CheckedInt.h:186:31: error: const_cast to 'bool', which is not a reference, pointer-to-object, or pointer-to-data-member static const bool value = const_cast<bool>(IntegerType(-1) <= IntegerType(0)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./../../dist/include/mozilla/CheckedInt.h:294:27: note: in instantiation of template class 'mozilla::detail::IsSigned<unsigned int>' requested here bool IsTSigned = IsSigned<T>::value, ^ ./../../dist/include/mozilla/CheckedInt.h:350:10: note: in instantiation of default argument for 'IsInRangeImpl<unsigned int, unsigned long>' required here return IsInRangeImpl<T, U>::run(x); ^~~~~~~~~~~~~~~~~~~ ./../../dist/include/mozilla/CheckedInt.h:574:26: note: in instantiation of function template specialization 'mozilla::detail::IsInRange<unsigned int, unsigned long>' requested here mIsValid(detail::IsInRange<T>(value)) ^ /var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:2097:35: note: in instantiation of function template specialization 'mozilla::CheckedInt<unsigned int>::CheckedInt<unsigned long>' requested here CheckedInt<uint32_t> replen = repstr->length(); ^ In file included from /var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:20: ./../../dist/include/mozilla/CheckedInt.h:186:31: error: const_cast to 'bool', which is not a reference, pointer-to-object, or pointer-to-data-member static const bool value = const_cast<bool>(IntegerType(-1) <= IntegerType(0)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./../../dist/include/mozilla/CheckedInt.h:295:27: note: in instantiation of template class 'mozilla::detail::IsSigned<unsigned long>' requested here bool IsUSigned = IsSigned<U>::value, ^ ./../../dist/include/mozilla/CheckedInt.h:350:10: note: in instantiation of default argument for 'IsInRangeImpl<unsigned int, unsigned long, false>' required here return IsInRangeImpl<T, U>::run(x); ^~~~~~~~~~~~~~~~~~~ ./../../dist/include/mozilla/CheckedInt.h:574:26: note: in instantiation of function template specialization 'mozilla::detail::IsInRange<unsigned int, unsigned long>' requested here mIsValid(detail::IsInRange<T>(value)) ^ /var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/js/src/jsstr.cpp:2097:35: note: in instantiation of function template specialization 'mozilla::CheckedInt<unsigned int>::CheckedInt<unsigned long>' requested here CheckedInt<uint32_t> replen = repstr->length(); ^ 2 errors generated. make[5]: Leaving directory `/var/tmp/paludis/www-client-firefox-21.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/js/src' make[5]: *** [jsstr.o] Error 1 make[4]: *** [libs_tier_js] Error 2 ========= Created attachment 352656 [details]
build log showing clang linking error, if ssse3 detection is not moved in configure.in
A proper solution needs to determine the availablity of ssse3 using clang, like it is done for gcc builds. However, the configure test tailored for gcc does not play well with clang, shown by the build log.
Greetings
Created attachment 352898 [details, diff]
firefox-22.0.ebuild.patch
Note:
- FF 22.0 + clang does not segfault dromaeo.com tests anymore, when methodjit is enabled, same applies to ion js engine -> reflect this in firefox-22.0.ebuild.patch
- I had a weird upgrade bug: After emerging/paluding FF22.0 successfully and starting FF, pages would not load - typing a site in the address bar and using web dev tools pane, network log said "GET <any-site.us>" and nothing happened. A couple of seconds later FF responds with the usual "network connectivity problem" page. However, I upgraded on amd64 and x86, and this behavior was only observed on amd64.
-> Using a fresh profile, renaming the old as backup, solved this problem.
-> I imported bookmarks from the backuped profile and installed a couple of addons into the fresh profile and deleted the old one.
-> If this happens to you, either rename old profile or please investigate further into this if you have the merits to do so. Report back if you can. However, I suspect this was due to an error specific to my profile as I couldn't reproduce it on another machine.
Greetings
Created attachment 361618 [details, diff]
firefox-24.0-r1.ebuild.patch
Created attachment 361630 [details, diff]
/etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.x.patch
(In reply to cmuelle8 from comment #37) > Created attachment 361618 [details, diff] [details, diff] > firefox-24.0-r1.ebuild.patch Latest clang from trunk has a problem with MOZINLINEs, so you might have to disable-replace-malloc / disable-jemalloc and comment out jemalloc export in the ebuild. Here are the errors I got clang++ -o mozalloc.o -c -DXP_LINUX -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -I../../xpcom -I/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc -I. -I../../dist/include -I/usr/include/nspr -I/usr/include/nss -fPIC -Qunused-arguments -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags -march=native -pipe -fomit-frame-pointer -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -O4 -fomit-frame-pointer -Qunused-arguments -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MP -MF .deps/mozalloc.o.pp /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp clang: warning: -O4 is equivalent to -O3 In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:198:21: error: replacement function 'operator new' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:204:21: error: replacement function 'operator new' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:210:21: error: replacement function 'operator new[]' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:216:21: error: replacement function 'operator new[]' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:222:21: error: replacement function 'operator delete' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:228:21: error: replacement function 'operator delete' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:234:21: error: replacement function 'operator delete[]' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ make[5]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu/memory/mozalloc' make[4]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu' make[3]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu' make[2]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/obj-i686-pc-linux-gnu' make[1]: Leaving directory `/var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release' ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ In file included from /var/tmp/paludis/www-client-firefox-24.0-r1/work/mozilla-release/memory/mozalloc/mozalloc.cpp:29: ../../dist/include/mozilla/mozalloc.h:240:21: error: replacement function 'operator delete[]' cannot be declared 'inline' MOZALLOC_EXPORT_NEW MOZALLOC_INLINE ^ ../../dist/include/mozilla/mozalloc.h:44:27: note: expanded from macro 'MOZALLOC_INLINE' # define MOZALLOC_INLINE MOZ_ALWAYS_INLINE_EVEN_DEBUG ^ ../../dist/include/mozilla/Attributes.h:42:75: note: expanded from macro 'MOZ_ALWAYS_INLINE_EVEN_DEBUG' # define MOZ_ALWAYS_INLINE_EVEN_DEBUG __attribute__((always_inline)) MOZ_INLINE ^ ../../dist/include/mozilla/Attributes.h:20:33: note: expanded from macro 'MOZ_INLINE' # define MOZ_INLINE inline ^ 8 errors generated. make[5]: *** [mozalloc.o] Error 1 make[4]: *** [libs_tier_base] Error 2 make[3]: *** [tier_base] Error 2 make[2]: *** [default] Error 2 make[1]: *** [realbuild] Error 2 make: *** [build] Error 2 Created attachment 362036 [details, diff] /etc/portage/patches/www-client/firefox/928808_no_inline.patch (In reply to cmuelle8 from comment #39) > (In reply to cmuelle8 from comment #37) > > Created attachment 361618 [details, diff] [details, diff] [details, diff] > > firefox-24.0-r1.ebuild.patch > > Latest clang from trunk has a problem with MOZINLINEs, so you might have to > disable-replace-malloc / disable-jemalloc and comment out jemalloc export in > the ebuild. > Solvable, though still a WIP, using https://bug928808.bugzilla.mozilla.org/attachment.cgi?id=820593 I'll attach it to this bug for convenience. Currently, starting from stock portage tree, you need to put two of the attachments "as is" into - /etc/portage/patches/www-client/firefox/928808_no_inline.patch - /etc/portage/patches/www-client/firefox/firefox-24.0-clang-3.4svn.patch - apply the ebuild patch to the firefox ebuild see third attachment to this bug - make ar, nm tools of binutils use llvm linker plugins see bug #462554 - patch mozcoreconf-2.eclass to allow passing correct optimization flags see bug #462488 It's not pretty and i have not set up an overlay for this, sorry. If someone would like to include this into his/her overlay, go ahead and post to this bug. Greetings cmuelle8 This is an old bug. I have successfully installed (and am currently using) www-client/firefox-52.2.0 sys-devel/clang-3.9.1. Should this bug be closed? Please ignore my comment above. Upon closer inspection, it turns out that lto was not actually being set when building firefox. If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team |