I've run into an intersting problem where CXXFLAGS are not being set properly on 586 CHOSTS. IF the CXXFLAGS are explicitly set by specifying them in make.conf then there is no problem. If, however, the CXXFLAGS are not explicitly set, then the system creates its own CXXFLAG specification to fill-in the gap. Interestingly, the system's CXXFLAG selection is WRONG. The system appears to use a 686-CHOST compatible setting by default, regardless of whether or not a 686-CHOST is in use. The example I will use to illustrate this bug will use 586-CHOST settings for -march=pentium (even though the actual machine in use is a P3). In the first case, everything is normal. The CXXFLAGS are explicitly specificed in make.conf and the CXXFLAGS in the environment (as noted by emerge --info) are correct: # cat /etc/make.conf CHOST="i586-pc-linux-gnu" CFLAGS="-march=pentium" CFLAGS="${CFLAGS} -O2" CFLAGS="${CFLAGS} -fomit-frame-pointer" CFLAGS="${CFLAGS} -pipe" CXXFLAGS="${CFLAGS}" ... # emerge --info Portage 2.1_pre6-r3 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r1 i686) ================================================================= System uname: 2.6.15-gentoo-r1 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.14 distcc 2.18.3 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-march=pentium -O2 -fomit-frame-pointer -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" ... Now look at what happens when we comment-out the CXXFLAGS line in /etc/make.conf and the CXXFLAGS are not explicitly set: The system doesn't find the CXXFLAG setting, and inserts its own. Unfortunately, it inserts a specification for -mcpu=i686 when the CHOST in use is actually 586!!! # cat /etc/make.conf CHOST="i586-pc-linux-gnu" CFLAGS="-march=pentium" CFLAGS="${CFLAGS} -O2" CFLAGS="${CFLAGS} -fomit-frame-pointer" CFLAGS="${CFLAGS} -pipe" #CXXFLAGS="${CFLAGS}" ... # emerge --info Portage 2.1_pre6-r3 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r1 i686) ================================================================= System uname: 2.6.15-gentoo-r1 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.14 distcc 2.18.3 i586-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-march=pentium -O2 -fomit-frame-pointer -pipe" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" ... For reasons that are not clear, the system is making two errors: 1) it is selecting the wrong CPU type (in this case i686 instead of i586) 2) it is using the deprecated -mcpu=<whatever> setting instead of -march=<whatever> Granted, the user could avoid this problem altogether by explicitly specifying the CXXFLAGS in make.conf, but the system should not go about creating incorrect substitutions. Additionally, as it is accepted practice to build for slower arches on faster boxes, I would hope that this bug report would not be summarily dismissed.
The profile has a CHOST of i686, so I don't see a problem of us using those CXXFLAGS. You have to specify your CHOST to be i586, so you should specify your CFLAGS and CXXFLAGS as well. Also, it looks like you have an i686, so I'm not sure why you want to specify i586... wolf31o2: your opinion? The mcpu is annoying, but we might want to leave that a bit longer. I vote WONTFIX.
(In reply to comment #1) > The profile has a CHOST of i686, so I don't see a problem of us using those > CXXFLAGS. You have to specify your CHOST to be i586, so you should specify > your CFLAGS and CXXFLAGS as well. The CHOST has been specified as 586. A properly designed, fault tolerant system would not insert a CXXFLAG that would b0rk the system should the user fail to un-comment any given setting. But I guess we're not looking at this from a fault tolerance perspective. > I'm not sure why you want to specify i586... Mark, I think you're missing the point -- I specifically mentioned in the original report that I am building on a 686-class box for deployment on a 586-class box. In this context the bug is a major system breaker -- the system won't function properly after the disk subsystem is moved.
We have no code in place *anywhere* to make automatic judgements for you regarding CHOST/CFLAGS/CXXFLAGS. When you change one, you need to change them all (if necessary). I don't think it is worth our time and energy to try to assume anything for the user. Remember that Gentoo is there to *allow* you to do what you want, not to try to predict what you want and guess on a possible solution for you. As Mark has already said, I completely agree with WONTFIX, as it would require some *very* serious bash-fu to actually implement the changes that you wish.
no problem. once i realized that i had commented-out the CXXFLAG, i slammed my head against the monitor for being so stupid and fixed the problem. i just thought you guys would find the error to be noteworthy, insofar as gentoo is inserting bad information where information did not otherwise exist. i agree, the problem is best avoided by making good choices. thanks for your time.
