Nikos Chantziaras posted on Tue, 28 Sep 2010 21:30:34 +0300 as excerpted: > On 09/28/2010 08:03 PM, Zhu Sha Zang wrote: >> I have some machines running gentoo and every machine running under >> AMD Processors (64-bit profile), everything is right. Every source code >> compile fine. >> >> But, some machines, i've installed under Intel Core 2 Quad or i7 >> processor and this machines have problem compile especific 2 packages: >> >> glibc (>=2.11.2) and lvm2 (2.02.73-r1) >> >> It's weird, don't compile in any intel processor machine. >> >> Take a example of emerge --info uner i7 machine. >> >> CFLAGS="-march=core2 -msse4 -mcx16 -mpopcnt -msahf -O2 -pipe" > > Maybe use some sane CFLAGS, like removing -msse4 -mcx16 -mpopcnt -msahf > might help.
Agreed, but more precisely, if you know your CPU does have those instructions, try something simple (like just "-march=core2 -O2 -pipe") when you have problems, but you can leave them there for normal compiles. In particular, glibc can be sensitive to over-optimization, and since it's so core a package -- your whole system will break if it breaks, traditionally, the glibc ebuilds back off on optimizations, removing many of them. You can trace this thru the glibc ebuild, into the common eblit, and from there into flag-o-matic.eclass. In particular in flag-o-matic, see the strip-flags and setup-allowed-flags functions. Also note, and this just might be where you're running into problems, that on multi-lib profiles such as normal amd64 (with both 32-bit and 64-bit libs, unless you're running a no-multilib profile as I've been doing here for some time), glibc is one of a handful of packages that compiles multiple times, for BOTH 64-bit and 32-bit. So for glibc, gcc, sandbox, and possibly binutils, you'll want to be *SURE* that all your flags will work in 32-bit mode as well as 64-bit mode. If some of those -m flags only apply to 64-bit mode... Finally, let me mention -march=native. If you're actually compiling on your target machine (and not using distcc or the like on other machines with different allowed instructions), -march=native will include all safe -m options for your machine, without you having to enumerate them specifically. IIRC, -march=native was added with gcc-4.4, so it's relatively new and isn't as widely documented as the other -march options. Meanwhile, in the context of -march, both =native and traditionally specified, it's also worth noting for future reference that gcc-4.5 (which isn't stable yet, and is either still hard-masked or just recently ~arch, but I'm running it without issue, thanks to flameeyes' tinderbox testing and early bug-filing) enables some new features on some CPUs. It's thus quite possible with some of the newer instruction sets that -march=native and the specific -march=targets will cause a bit of an issue in the gcc-4.5 upgrade. (I noticed it here, because I build for my atom based netbook in a dedicated 32-bit chroot on my older 3-digit Opteron based main machine. When I switched it to gcc-4.5, the -march= I was using activated some new instructions not available on my older build machine, and packages, including bzip2 and sed, pretty critical for normal emerges, broke. I had to copy gcc-4.4 compiled binaries off of my netbook back to the build- image to get back in business, then experiment a bit with various settings until I found a cflags set that worked on both the build-system and the atom. All this because gcc-4.4 ignored those instructions even tho the - march I had set allowed them, while gcc-4.5 made use of them, thus triggering the breakage, until I turned off the instructions it was trying to use, now. Of course, if I was building on the netbook itself, that shouldn't have been a problem.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
