OK, I have differing CFLAGS and CXXFLAGS, because I use -freorder-blocks-and-partition in my CFLAGS and it doesn't work for C++ (well, assertions). GCC just emits a warning, but that warning unfortunately causes many config scripts to bail out, and since it doesn't work anyway for C++/assertions, I just don't put it in my CXXFLAGS. Therefore, imagine my dismay while troubleshooting an unrelated error to find ttmkfdir using CFLAGS instead of CXXFLAGS to compile C++ code: From the output: x86_64-pc-linux-gnu-g++ -Wall -pedantic -I/usr/include/freetype2 -march=k8 -msse3 -pipe -fdirectives-only -frename-registers -fweb -ftree-vectorize -freorder-blocks-and-partition -combine -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -c encoding.cpp -fPIC -DPIC -o .libs/encoding.o cc1plus: note: -freorder-blocks-and-partition does not work with exceptions As I said, an unrelated error later caused portage to error out with the following. Note the juxtaposition of CXX and CFLAGS, possibly the cause of the above: * ERROR: x11-apps/ttmkfdir-3.0.9-r3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2391: Called die * The specific snippet of code: * emake CXX="$(tc-getCXX)" OPTFLAGS="${CFLAGS}" DEBUG="" || die "emake failed" * The die message: * emake failed Why is it using CFLAGS instead of CXXFLAGS? I can provide full emerge --info on request, but I don't see how it matters given the particular facts of the bug. CFLAGS simply shouldn't be used to invoke G++, and doing so is a bug, any way you look at it.
Fixed in CVS, thanks!
