Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 59506 (qa-cflags) - [TRACKER] packages that do not respect CFLAGS and CXXFLAGS
Summary: [TRACKER] packages that do not respect CFLAGS and CXXFLAGS
Alias: qa-cflags
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Gentoo Quality Assurance Team
Keywords: Tracker
: 319559 (view as bug list)
Depends on: 241044 428070 619436 646012 652172 51593 58956 59280 59507 59508 59509 59510 59511 59513 59514 59537 59709 67070 69678 86874 112432 143661 176240 190534 220739 238106 241052 511098 526194 530928 562164 619674 620532 622576 646756 674918 687412
  Show dependency tree
Reported: 2004-08-05 04:56 UTC by Ciaran McCreesh
Modified: 2019-10-13 13:59 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Ciaran McCreesh 2004-08-05 04:56:13 UTC
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:

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.
Comment 1 Ciaran McCreesh 2004-08-05 09:37:58 UTC
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.
Comment 2 Matthew Kennedy (RETIRED) gentoo-dev 2004-08-05 21:57:24 UTC
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

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.
Comment 3 Ciaran McCreesh 2004-08-06 05:15:09 UTC
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.
Comment 4 Matthieu Sozeau (RETIRED) gentoo-dev 2004-08-18 10:00:17 UTC
The ocaml compiler intentionaly ignores user's CFLAGS !
Comment 5 Ciaran McCreesh 2004-08-18 10:06:50 UTC
Intentionally ignoring CFLAGS is no good. It breaks things.
Comment 6 Martin Holzer (RETIRED) gentoo-dev 2004-08-19 05:31:18 UTC
this is really a great problem
see the hundreds of thousand bugs about wrong mplayer flags.
any good idea how to solve this ?
Comment 7 Daniel Black (RETIRED) gentoo-dev 2004-08-19 07:36:14 UTC
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 :-)
Comment 8 Ciaran McCreesh 2004-08-19 07:46:23 UTC
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.
Comment 9 Ferris McCormick (RETIRED) gentoo-dev 2004-09-24 05:39:57 UTC
Add myself to CC list.
Comment 10 Ferris McCormick (RETIRED) gentoo-dev 2005-03-27 09:08:15 UTC
x11-libx/fox=1.3.6-r2 also ignores CXXFLAGS, substituting 'no-optimization, no-architecture-consideration.'
Comment 11 Ernst Bachmann 2005-07-22 04:54:57 UTC
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. 
Comment 12 Ferris McCormick (RETIRED) gentoo-dev 2005-11-13 06:54:53 UTC
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.
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2007-06-30 21:54:15 UTC
Nothing left here.
Comment 14 Ferris McCormick (RETIRED) gentoo-dev 2007-08-28 14:29:31 UTC
This is a useful tracker, and for sparc at least it is an ongoing problem.  We add to this bug as the need arises.
Comment 15 Mark Loeser (RETIRED) gentoo-dev 2010-09-10 19:27:36 UTC
*** Bug 319559 has been marked as a duplicate of this bug. ***
Comment 16 Martini peres 2012-03-05 12:08:25 UTC
This comment has been removed because it contained spam. -- idl0r
Comment 17 Larry the Git Cow gentoo-dev 2018-09-01 09:01:38 UTC
The bug has been referenced in the following commit(s):

commit 9acfbf506aef6feb95d6d8c6896bc840fd609f2e
Author:     Jeroen Roovers <>
AuthorDate: 2018-09-01 08:52:13 +0000
Commit:     Jeroen Roovers <>
CommitDate: 2018-09-01 09:01:34 +0000

    net-libs/libssh: Set -DWITH_STACK_PROTECTOR=OFF
    The build system injects -fstack-protector _after_ CFLAGS, which means
    that when CFLAGS define a stronger SSP, this lowers its protection
    instead of improving it.
    Additionally, the test for the compiler flag succeeds on HPPA when it
    shouldn't, causing the build to fail later on:
    In file included from src/agent.c:53:0:
    include/libssh/priv.h:169:4: error: #error "Your system must provide a __func__ macro"
    Package-Manager: Portage-2.3.48, Repoman-2.3.10

 net-libs/libssh/libssh-0.7.4.ebuild    | 1 +
 net-libs/libssh/libssh-0.7.5-r2.ebuild | 1 +
 net-libs/libssh/libssh-0.8.1.ebuild    | 1 +
 net-libs/libssh/libssh-9999.ebuild     | 1 +
 4 files changed, 4 insertions(+)