It would appear that the make.conf CFLAGS ceased to be incorporated into most ebuilds around sometime in the last year. Records of *most* builds on 2 machines do not contain the -march=prescott or -march=amdfam10 options (as well as -O2 or -pipe) which are specified in /etc/make.conf. Presumably this requires rebuilding all ebuilds over the last 3 months to get architecture specific binaries. Reproducible: Always Steps to Reproduce: 1. emerge lcms | grep "march=prescott" 2. The architecture specification stops appearing in gcc lines sometime between Apr 6, 2009 and Feb 18, 2010. lcms is used as a specific example where old/new build listings can be examined. The problem (missing make.conf CFLAGS) appears to apply to hundreds of package builds over the last year or more. Actual Results: CFLAGS specified in make.conf are lost from gcc lines for most ebuilds. The ability to "tune" CFLAGS for the machine architecture was one of the nicer features of Gentoo. If Gentoo no longer supports it that presents an argument to switch to another Linux distribution. Expected Results: CFLAGS from make.conf should be respected and included in the gcc lines (as they used to be). It is interesting to note that only python-updater appears to still include the CFLAGS arguments. It is the core system utilities (X, glib, gtk+, gnome, etc.) where CFLAGS specific to the architecture should be most respected. Python based programs are presumably only used where performance is not critical.
You need report bugs against specific packages, so I'm taking media-libs/lcms as you mentioned it as example: [ .. ] -I../../include -I../../include -I../../utils/common -I../../utils/common -march=core2 -msse4.1 -O2 -pipe -c linkicc.c [ .. ] Appears to working as it should.
Created attachment 257692 [details] Small sample make.conf Minimized make.conf. Used to build gst-plugins-flac and gst-plugins-soup which showed up in today's re-emerge list. The listing files for various are for ebuilds grepping for the string 'prescott' (which is in the make.conf CFLAGS). The listing files which have starred (**) are those which contain the string "prescott" in the gcc lines (e.g. those which picked up CFLAGS). It appears that CFLAGS from make.conf stopped making it into the gcc command flags sometime around Apr-June of 2009. Current versions: Portage: sys-apps/portage-2.1.9.25 USE="doc (ipc) -build -epydoc -python3 (-selinux)" Python: python-2.7.1 If you need the versions of any other packages I need to know what they are.
Created attachment 257693 [details] gst-plugins-flac emerge listings marked for those with prescott
Created attachment 257695 [details] gst-plugins-soup emerge listings marked for those with prescott
The gst-plugins ebuilds were provided as an example of other ebuilds which have lost their CFLAGS settings. This is in contrast to other ebuilds such as tightvnc or blas-atlas where the CFLAGS tend to be explicitly ignored or modified in strange ways by the package configuration process (doing what "they" think is right rather than what the user thinks is suitable for the environment). The summary for this bug should probably be changed to "Many emerges ignore" or similar rather than "media-libs/lcms ignores" since that misleads one into thinking it is a lcms problem rather than an emerge problem [1]. I simply wanted to provide lcms as an initial example. The problem is not 'universal' however since a recent run (python-updater Nov 29 2010 17:09) *did* incorporate the make.conf CFLAGS. 1. I don't think I can change the summary myself but admins may be able to.
Question: Does portage look for /usr/local/etc/make.conf ??? If it finds /usr/local/etc and does not find make.conf, does it fall back to /etc/make.conf? If not, then this may be the source of the problem. I've run into this problem before that if /usr/local exists but is only "partial" from the perspective of installed components one does not get errors if those components are missing or/outdated by the standard system hierarchy. In this scenario, there would be a bug in python-updater because it *is* using /etc/make.conf when there is no /usr/local/etc/make.conf. The ideal behavior would be warnings/errors when a /usr/local configuration or executable file or lack thereof) is "trumping" a standard system file. An alternate behavior is to require the use of /usr/local to be an explicit argument to portage.
Ok, I think I now know what is going on. It would appear that environment CFLAGS override make.conf CFLAGS. So if one has make.conf setup with CFLAGS="-march=amdfam10 -O2" and then uses the command CFLAGS=-ggdb emerge ed one loses the make.conf CFLAGS settings. I believe I have seen a document (from Gentoo?) which suggested there was a priority for CFLAGS settings but cannot seem to find it right now. The implication is that there is no "logical or" between environment CFLAGS and make.conf CFLAGS. This is annoying because the way my system is setup I do not want to compile all packages with -ggdb, but only selected packages (e.g. system libraries and gnome libraries). The lack of a CFLAGS logical or means I would have to edit the CFLAGS in make.conf for each build, or only specify CFLAGS in the environment. This makes it difficult to setup a system where one sets CFLAGS for the machine in make.conf but sets the debugging flags on an emerge by emerge basis. The bug can be resolved by making the priority/effect of CFLAGS processing clearer in documents such as The Compilation Optimization Guide: http://www.gentoo.org/doc/en/gcc-optimization.xml There may be other documents which discuss make.conf vs. environment CFLAGS which people more familiar with the documentation may be aware of and they should be reviewed as well. It should be noted as well that the macro CC build commands found in many emerge listings hide the precise flags used to build a package -- something there should be an emerge option to correct.
reopen per Comment #7, for possible documentation improvement(?)
Per-package CFLAGS are entirely unsupported. Last I heard, 'CFLAGS="foo" emerge bar' . . . shouldn't even *work*. It's not like doing 'USE="foo" emerge bar' or similar. There's no such "CFLAGS priority" document that we've produced. We've never officially supported any hacks for per-package flags (/etc/env/ is a common one), or supporting any methods of passing global variables besides using make.conf.
