Bugzilla Bug 59506

Metabug for ebuilds which kill user-supplied CFLAGS. This is a Very Bad Thing
(TM):

* Killing -march/-mcpu will force kernel emulation for certain opcodes
(especially for floating point) on certain processors. This is *really* slow.

* Stripping certain ABI flags will kill linkage. This will lead to either
crashes or horrid explosive failure on non-static binaries.

* Stripping certain ABI flags will produce invalid code for certain CPUs. For
example, we might end up producing big endian code for little endian CPUs, or
code which assumes that the %g0 register is always zero when it isn't.

gentoo-dev post:
http://marc.theaimsgroup.com/?l=gentoo-dev&m=109131955117290&w=2

Correct behaviour is to use flag-o-matic's strip-flags. This isn't perfect, but
it means that when we have to add in new allowed flags, we only have to do it
in one place rather than in several hundred ebuilds.

Additional reason:

* When killing a user's march/mcpu/mtune and replacing it with a vendor-supplied auto-detected CPU setting, this breaks binaries (GRP and crossbuilding). For example, I might be building generic i686 stages on my athlon-xp.

Someone feels dev-lisp/clisp and dev-lisp/mzscheme are problems
because of this.  Quite frankly I dont have the time to determine what
flags and combinations thereof cause build or runtime failures.

You can take a look at dev-lisp/clisp and get an idea of the time
consuming and complicated flag-o-matic logic required to get CLISP
built.  It is a maintenance nightmare.  Even with that logic, I know
people are still encountering problems on architectures I can't test
myself.  

I understand all your reasons.  They look like good ones to me.  I'm
open to suggestions, however if you insist on filtering CFLAGS, then
feel free to do all the work.

Mike -- how about adding in a strip-optimisation-flags or somesuch to
flag-o-matic? It'd have the same kind of behaviour as strip-flags but would
also remove optimisations.

The ocaml compiler intentionaly ignores user's CFLAGS !

Intentionally ignoring CFLAGS is no good. It breaks things.

this is really a great problem
see the hundreds of thousand bugs about wrong mplayer flags.
any good idea how to solve this ?

Create some tool that performs QA when ebuilding the product.

There is also scope for other checks such as:
- verify dependancies based on files accessed
- doing a rough check on FHS compliance
- determining files its about to cobber and the packages that provide that
- checking runtime dependancies based on script languages, dynamic libraries etc.

Or if its mainly mplayer - infiltrate the mplayer dev team and commit out all CFLAGS :-)

I've modified flag-o-matic locally to allow -D__CIARANM_WAS_HERE__ through. I'm
now building lots and lots of apps whilst logging the compiles, and later on
I'll grep through for possible matches.

I still like the "get required flags" idea.

Add myself to CC list.

x11-libx/fox=1.3.6-r2 also ignores CXXFLAGS, substituting 'no-optimization,
no-architecture-consideration.'

Just posted a fresh bug #99896, but after finding this report, I'd thought I'd 
add the info here as well. 
 
glibc ebuild filters the "-mno-tls-direct-seg-refs" gcc-3.4.4+ option, which 
makes it impossible to build a NPTL glibc which would run nicely under Xen. 
 
The culprit is the "strip-flags" function in flag-o-matic.eclass, adding 
-mno-tls-direct-seg-refs as known-good flag there locally solves the problem 
for me. 

It seems that sci-libs/lapack-atlas just went stable on sparc, and I notice
that
the build completely ignores my CFLAGS='-O2 -mcpu=ultrasparc -pipe' and
substitutes:
-fomit-frame-pointer -O3 -funroll-all-loops
This is a horrible choice for sparc: omit-frame-pointer is unneeded and the
others are probably lost in the fact that this defaults to -mv7 architecture,
guaranteeing the slowest possible execution times.  (The g77 flags are (flag
is)
just -O, so the fortran portion is probably a little worse code that the c
portion.)
I thought this was taken care of, but maybe only for blas-atlas.

Nothing left here.

This is a useful tracker, and for sparc at least it is an ongoing problem.  We
add to this bug as the need arises.