When using clang, some people experiment with optimization flag "-O4". This will not be passed to ./configure since mozcoreconf sorts out individually what to feed to --enable-optimize. Since custom-cflags is an expert option anyway, mozcoreconf-2.eclass should not be in the way of people trying out experimental stuff. There are other obstacles when trying to build firefox with clang+lto, which might be overcome using a custom patch applied using epatch_user in FF ebuilds, so this is a small issue in line, but easily fixable. I used the following patch, but it might be better to just pass on the value of -O* contained in user cflags, since this is what the user wants, especially when instruction the ebuild to use "custom-cflags" via use flags to the ebuild. --- /var/paludis/repositories/gentoo/eclass/mozcoreconf-2.eclass~ 2013-03-20 15:09:13.000000000 +0100 +++ /var/paludis/repositories/gentoo/eclass/mozcoreconf-2.eclass 2013-03-20 09:16:21.000000000 +0100 @@ -161,6 +161,8 @@ mozconfig_annotate "from CFLAGS" --enable-optimize=-O0 elif [[ ${ARCH} == ppc ]] && has_version '>=sys-libs/glibc-2.8'; then mozconfig_annotate "more than -O1 segfaults on ppc with glibc-2.8" --enable-optimize=-O1 + elif is-flag -O4; then + mozconfig_annotate "from CFLAGS" --enable-optimize=-O4 elif is-flag -O3; then mozconfig_annotate "from CFLAGS" --enable-optimize=-O3 elif is-flag -O1; then Reproducible: Always
(In reply to comment #0) > Since custom-cflags is an expert option anyway, mozcoreconf-2.eclass should > not be in the way of people trying out experimental stuff. Furthermore, consider the use flag help for both, custom-optimizations and custom-cflags. It discourages their use, underlining their experimental character. If those flags are enabled the eclass should try it's best to stay out of the users way and only filter out a minimum set in *FLAGS. Greetings
Created attachment 342808 [details] mozcoreconf-2.custom-opts.patch Also, on x86, custom-optimization is currently not usable: elif [[ ${ARCH} == x86 ]]; then mozconfig_annotate "less then -O2 causes a segfault on x86" --enable-optimize=-O2 elif use custom-optimization || [[ ${ARCH} =~ (alpha|ia64) ]]; then the second elif is never reached, since the first matches always on that arch. An updated, overhauled patch is attached. It works here, but please retest before applying. Thx
Created attachment 344004 [details] mozcoreconf-2.eclass.set-host-triple.custom-optimize.patch move config.guess patch from bug #462608 into the eclass - we do not need to "guess" the host on Gentoo systems, just use CHOST of make.conf or (wrt paludis' cave) bashrc - see bug #462608 cmt #8 for details
Created attachment 345420 [details, diff] mozcoreconf-2.eclass.patch "Specifying the host without specifying the build /should be avoided/, as configure may (and once did) assume that the host you specify is also the build, which may not be true." source: http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html Some research into this lead to an update of the attached patch. I subsequently propose to remove --target= --build= from the mozilla /ebuilds/ and fit them into the eclass, as they are essential to every mozilla build. This keeps setting --host to avoid mis-detection of cross-compilation in some cases (as was done previously). I've put a thorough comment within the eclass for fast reference. #################################### # # BUILD / HOST / TARGET setup # # http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html says # If [c]host and [c]target are the same, but [c]build is different, # you are using a cross-compiler to build a native for [chost]. # the machine you are building on (--build), CBUILD # the machine that you are building for (--host), CHOST # the machine that GCC will produce code for (--target), CTARGET # # # Mozilla's configure terms differ to this for historic reasons, i.e. # ./configure --host=${CBUILD} --build=${CHOST} --target=${CTARGET} # The meaning of build and host is swapped. # # ./configure defaults for most mozilla software are # to guess --host, i.e. CBUILD in gcc terminology # and to set --build := --target := --host # # Guessing CBUILD (here: --host) is error-prone. # make.conf hardcodes CHOST on most Gentoo installs. # We use CHOST as a fallback to CTARGET here. # # If CTARGET is not set, configure might miss a native build, # when (config.guessed CBUILD) != (hardcoded CHOST). Passing # CBUILD (here: --host) prevents this, bug #462608 comment #8. # # # http://www.gentoo.org/proj/en/base/embedded/cross-development.xml # asserts $CHOST == $CTARGET, just binaries here, no toolchains # mozconfig_annotate "" --build=${CHOST} # mozconfig_annotate "" --build=${CTARGET:-${CHOST}} # should both do the same if ENVs are set according to the guide # ####################################
Thanks for your efforts. However, it should be noted that mozilla's use of --build and --host and --target does *not* match that of autotools' standards. mozcoreconf-v4 manages this as best it can (and has been confirmed to work on crossdev, too). I will add the ability to set -O4 when custom-optimization is set, however all of the other filters will remain as-is. commit 0b5d23ceefd8697aa668943a54a21ef4e0309be5 Author: Ian Stakenvicius <axs@gentoo.org> Date: Mon Jul 25 14:50:27 2016 -0400 mozcoreconf-v4.eclass: allow -O4 when custom-optimization flag is set End-users want to experiment with clang and -O4, so let them. Bug: http://bugs.gentoo.org/462488
