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 85ADD1387FD for ; Thu, 27 Mar 2014 04:42:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C9658E0A90; Thu, 27 Mar 2014 04:42:43 +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 CB750E0A68 for ; Thu, 27 Mar 2014 04:42:42 +0000 (UTC) Received: from [192.168.88.43] (unknown [96.241.16.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: tetromino) by smtp.gentoo.org (Postfix) with ESMTPSA id DA37033FA95 for ; Thu, 27 Mar 2014 04:42:41 +0000 (UTC) Message-ID: <1395895307.23327.25.camel@rook> Subject: Re: [gentoo-dev] Re: crossdev and multilib interference From: Alexandre Rostovtsev To: gentoo-dev@lists.gentoo.org Date: Thu, 27 Mar 2014 00:41:47 -0400 In-Reply-To: <4392318.HzopIDRGrh@vapier> References: <53208139.2040509@gentoo.org> <1660834.UE1ARX9orZ@vapier> <5332FF19.1030707@gentoo.org> <4392318.HzopIDRGrh@vapier> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3JEXAzuvfq/61G/36owL" X-Mailer: Evolution 3.10.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Archives-Salt: 5c094a7e-1f40-4648-8b92-4a9638bcdd69 X-Archives-Hash: 689ce3239498d472e414c1e21f9dd2ea --=-3JEXAzuvfq/61G/36owL Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2014-03-26 at 22:41 -0400, Mike Frysinger wrote: > On Wed 26 Mar 2014 12:23:53 Ian Stakenvicius wrote: > > On 26/03/14 12:12 PM, Mike Frysinger wrote: > > > that's bs. people install crossdev to get a cross-compile > > > environment, not to get something that only works through `emerge`. > > > attempting to restrict it so it only works through `emerge` is > > > unacceptable and it has never been that way. > >=20 > > it -does- make sense though to limit anything that one wants to EMERGE > > with the crossdev, to require the use of cross-emerge. Would it not > > be possible to somehow ensure the crossdev tools are ignored > > in/removed from/cannot pollute the standard emerge environment? Are > > there any use cases where one -would- want the crossdev to be used in > > a standard emerge environment instead of using cross-emerge ? >=20 > you've lost me. when you `emerge-$CTARGET`, that package doesn't go anyw= here=20 > near your ROOT=3D/ system. it's entirely contained in /usr/$CTARGET/. >=20 > when you run `crossdev $CTARGET`, it installs all the standard $CTARGET-x= xx=20 > tools in /usr/bin. this isn't "polluting" the environment at all ... in = fact,=20 > they're living right alongside existing tools. >=20 > as i pointed out elsewhere in this thread, the problem is that multilib r= elies=20 > on automatic detection of the toolchain *failing* so that it falls back t= o the=20 > native value. in other words, when you run `./configure --host=3Di686-pc= -linux- > gnu`, it tries to find e.g. i686-pc-linux-gnu-ar. it doesn't exist so th= e=20 > fallback is used (plain `ar`). multilib is using these tuples so that th= e=20 > standard checks (autoconf/eclasses/etc...) trigger in the right ways for = the=20 > cpu/os/userland combinations. >=20 > since crossdev installs a full proper toolchain for the target, the one= =20 > multilib was using to lie now exists and its toolchain is used instead. > -mike Crossdev is "polluting the environment" in the specific case that we are talking about - secondary native ABIs on a multilib system. An amd64 multilib system is not expected to build MIPS binaries that would be hosted on itself. So of course anyone using amd64 undersands that mips-pc-linux-gnu-ar is part of a cross-compile toolchain, no matter whether it's in /usr/bin or /usr/libexec/crossdev or anywhere in the filesystem. However, an i686 crossdev on an amd64 multilib system is a fundamentally different situation. An amd64 multilib system *is* expected to build x86 binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is expected to be not a part of any cross-compile toolchain, but a part of the native toolchain for the machine's secondary native ABI. Especially when i686-pc-linux-gnu-ar is in /usr/bin. --=-3JEXAzuvfq/61G/36owL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJTM6wLAAoJEKRDAQ9PHUhgMUoP/jy/sDJvWkcJDDBJfqxcE0At Lmpxe9nus0HiL0YCzSEMSpfTyl3jSvYu7Ixl+6ZEMiDIext1U+oYDjbj/Jh7eTB2 7kSypZ2pndYO6GBrpNvFoFVlV6aWxlZ58VJyw757v/lbIG/nUGqXc2uGufq5u3nC 79ORFlARTAtgS3vKrxmDbx1R1RjxMkgNK+NtDdKgJyvoFNLDBPZLrbRAj/NPzoqO HipiRqYdI65DIxevrIIi1ZyUhAauBiy8Qu6NI9Dp/Av5wFhmSljAOFS8T4yaQGGa Li2o9PGcf3GcqGC3ACmouC+smnat+Gc1GEndbjaoC3QGqjnG6f33qYSNOCJZxGAL s7FkZlduFv7XcxpVjV7W3bz4Vc6BgyY/motW0riHcD3qhy6IB3zPtXGKXD+LxHvR mRhhLDogyjqFvoYFJ3FGQ6KUfGvcN+knwcF2zNM584oB9RKRJMJt9IWA4+x20WjA JUS3yrPSXFt8A2J/IrBB5TtAifdmbP6XBinZgDVgRn1/IFnoyZGo2rvSZSZJX3M8 YYsmstZ/HQN5m6Bz+caUY94ZA5gqH87pPwwlKPOevuVE7U2RUlm47DIwl3gac5w+ Uyba0nHAwmZGUO32xTuX0tz0z1q7uSSWLl3APutxBYbeDuZHsM3v0xk5gPuJgsF5 P6pZQ5AbhD6KTb93UGEg =xVCn -----END PGP SIGNATURE----- --=-3JEXAzuvfq/61G/36owL--