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.
*** Bug 319559 has been marked as a duplicate of this bug. ***
This comment has been removed because it contained spam. -- idl0r
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9acfbf506aef6feb95d6d8c6896bc840fd609f2e commit 9acfbf506aef6feb95d6d8c6896bc840fd609f2e Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2018-09-01 08:52:13 +0000 Commit: Jeroen Roovers <jer@gentoo.org> 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" Bug: https://bugs.gentoo.org/59506 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(+)
