From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 66A93138CC5 for ; Sun, 22 Mar 2015 14:06:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 404E6E0899; Sun, 22 Mar 2015 14:06:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F2A4AE0869 for ; Sun, 22 Mar 2015 14:06:22 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 9A7C5340BA4 for ; Sun, 22 Mar 2015 14:06:21 +0000 (UTC) Received: by igbud6 with SMTP id ud6so22632306igb.1 for ; Sun, 22 Mar 2015 07:06:19 -0700 (PDT) X-Received: by 10.42.166.1 with SMTP id m1mr15118919icy.10.1427033179574; Sun, 22 Mar 2015 07:06:19 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.64.128.168 with HTTP; Sun, 22 Mar 2015 07:05:59 -0700 (PDT) In-Reply-To: References: <20150319015612.GA7416@waltdnes.org> <20150319042026.GA7681@waltdnes.org> <2482967.XKl8GgfQej@navi> From: Mike Gilbert Date: Sun, 22 Mar 2015 10:05:59 -0400 Message-ID: Subject: Re: [gentoo-user] Will a 64-bit-no-multilib machine cross-compile 32-bit code? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 2ffaef5b-0dd0-4250-8c8b-443c1a8fd019 X-Archives-Hash: 58e0ead0ccb340c998c8fa769db7b6db On Sun, Mar 22, 2015 at 10:03 AM, Mike Gilbert wrote: > On Sat, Mar 21, 2015 at 3:52 PM, Fernando Rodriguez > wrote: >> On Saturday, March 21, 2015 8:46:10 AM Mike Gilbert wrote: >>> On Thu, Mar 19, 2015 at 12:20 AM, Walter Dnes wrote: >>> > CFLAGS="-O2 -march=atom -mno-cx16 -msahf -mmovbe -mno-aes -mno-pclmul - >> mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 - >> mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno- >> hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr >> -mno-xsave -mno-xsaveopt --param l1-cache-size=24 --param l1-cache-line- >> size=64 --param l2-cache-size=512 -mtune=atom -fstack-protector -mfpmath=sse - >> fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" >>> > >>> > Is that correct (assuming that's my output)? >>> > >>> >>> I should warn you against including all of those -mno-xxx flags. This >>> has been known to break the build process for packages like chromium, >>> which always wants to build with SSE4 support and toggles it off at >>> runtime. Passing -mno-sse4.1 causes a build failure as it tries to use >>> macros that are not defined. >>> >> >> Isn't it possible that removing it for all packages would cause a more subtle >> problem with another faulty ebuild (like a program crashing due to an illegal >> instruction)? > > Passing -march=atom should be sufficient to ensure that you don't get > any illegal instructions. The -mno-XXX flags are redundant, and MOSTLY > harmless. > > In the case of chromium, the build system adds -msse4.1 for specific > files (just the ones using SSE4.1 instructons). When you have > -mno-sse4.1, this takes precedence and the build fails. To put it another way: back in the day before gcc -march=native, nobody would have told you to put a bunch of -mno-xxx flags in your global CFLAGS. They would have told you to find the -march setting most appropriate for your processor.