[gentoo-amd64] Re: intel processors x gentoo

[Duncan]

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