From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1P0hhM-0001L7-V4 for garchives@archives.gentoo.org; Tue, 28 Sep 2010 21:26:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 61D9C1C032 for ; Tue, 28 Sep 2010 21:26:52 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by pigeon.gentoo.org (Postfix) with ESMTP id E7563E07BE for ; Tue, 28 Sep 2010 20:18:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P0gcs-0003cr-K5 for gentoo-amd64@lists.gentoo.org; Tue, 28 Sep 2010 22:18:10 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Sep 2010 22:18:10 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Sep 2010 22:18:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: intel processors x gentoo Date: Tue, 28 Sep 2010 20:18:03 +0000 (UTC) Message-ID: References: <4CA21FE9.3010203@yahoo.com.br> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies; GIT a971f44 branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c044458d-829f-46aa-8937-c7109727d48c X-Archives-Hash: 6333bec2b96d921fd45d7ed031254054 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 cod= e >> 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 (>=3D2.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=3D"-march=3Dcore2 -msse4 -mcx16 -mpopcnt -msahf -O2 -pipe" >=20 > 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=20 instructions, try something simple (like just "-march=3Dcore2 -O2 -pipe")= =20 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=20 so core a package -- your whole system will break if it breaks,=20 traditionally, the glibc ebuilds back off on optimizations, removing many= =20 of them. You can trace this thru the glibc ebuild, into the common eblit= ,=20 and from there into flag-o-matic.eclass. In particular in flag-o-matic,=20 see the strip-flags and setup-allowed-flags functions. Also note, and this just might be where you're running into problems, tha= t=20 on multi-lib profiles such as normal amd64 (with both 32-bit and 64-bit=20 libs, unless you're running a no-multilib profile as I've been doing here= =20 for some time), glibc is one of a handful of packages that compiles=20 multiple times, for BOTH 64-bit and 32-bit. So for glibc, gcc, sandbox,=20 and possibly binutils, you'll want to be *SURE* that all your flags will=20 work in 32-bit mode as well as 64-bit mode. If some of those -m flags=20 only apply to 64-bit mode... Finally, let me mention -march=3Dnative. If you're actually compiling on= =20 your target machine (and not using distcc or the like on other machines=20 with different allowed instructions), -march=3Dnative will include all sa= fe=20 -m options for your machine, without you having to enumerate them=20 specifically. IIRC, -march=3Dnative was added with gcc-4.4, so it's=20 relatively new and isn't as widely documented as the other -march options= . Meanwhile, in the context of -march, both =3Dnative and traditionally=20 specified, it's also worth noting for future reference that gcc-4.5 (whic= h=20 isn't stable yet, and is either still hard-masked or just recently ~arch,= =20 but I'm running it without issue, thanks to flameeyes' tinderbox testing=20 and early bug-filing) enables some new features on some CPUs. It's thus=20 quite possible with some of the newer instruction sets that -march=3Dnati= ve=20 and the specific -march=3Dtargets will cause a bit of an issue in the gcc= -4.5=20 upgrade. (I noticed it here, because I build for my atom based netbook i= n=20 a dedicated 32-bit chroot on my older 3-digit Opteron based main machine.= =20 When I switched it to gcc-4.5, the -march=3D I was using activated some n= ew=20 instructions not available on my older build machine, and packages,=20 including bzip2 and sed, pretty critical for normal emerges, broke. I ha= d=20 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 setting= s=20 until I found a cflags set that worked on both the build-system and the=20 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=20 triggering the breakage, until I turned off the instructions it was tryin= g=20 to use, now. Of course, if I was building on the netbook itself, that=20 shouldn't have been a problem.) --=20 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