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 9D0FB138CC5 for ; Sun, 22 Mar 2015 14:03:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9A38E0881; Sun, 22 Mar 2015 14:03:26 +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 ABAABE0817 for ; Sun, 22 Mar 2015 14:03:25 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (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 84B82340A50 for ; Sun, 22 Mar 2015 14:03:24 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so22781475ied.1 for ; Sun, 22 Mar 2015 07:03:22 -0700 (PDT) X-Received: by 10.42.166.1 with SMTP id m1mr15103971icy.10.1427033002446; Sun, 22 Mar 2015 07:03:22 -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:03:01 -0700 (PDT) In-Reply-To: <2482967.XKl8GgfQej@navi> References: <20150319015612.GA7416@waltdnes.org> <20150319042026.GA7681@waltdnes.org> <2482967.XKl8GgfQej@navi> From: Mike Gilbert Date: Sun, 22 Mar 2015 10:03:01 -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: e3c9d0e1-d7aa-492a-b75a-cc0fe8fdf5ef X-Archives-Hash: 0d8ce437cdd6d20ad6f49ce491d22286 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.