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 B390F1387FD for ; Thu, 27 Mar 2014 06:07:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E15D3E0A90; Thu, 27 Mar 2014 06:07:31 +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 AAE77E0A68 for ; Thu, 27 Mar 2014 06:07:30 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id EC48133FD54 for ; Thu, 27 Mar 2014 06:07:29 +0000 (UTC) From: Mike Frysinger To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: crossdev and multilib interference Date: Thu, 27 Mar 2014 02:07:36 -0400 Message-ID: <4273026.i7QpdYDi0u@vapier> Organization: wh0rd.org User-Agent: KMail/4.12.3 (Linux/3.13.0; KDE/4.12.3; x86_64; ; ) In-Reply-To: <1395895307.23327.25.camel@rook> References: <53208139.2040509@gentoo.org> <4392318.HzopIDRGrh@vapier> <1395895307.23327.25.camel@rook> 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 Content-Type: multipart/signed; boundary="nextPart12383269.EWHRuQmbAG"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Archives-Salt: a3cd66a0-e426-4ee4-867e-c64ccea0b452 X-Archives-Hash: 5c40413c5f3c814b76797b8aa7d29ecd --nextPart12383269.EWHRuQmbAG Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Thu 27 Mar 2014 00:41:47 Alexandre Rostovtsev wrote: > 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 `emer= ge`. > > > > 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 E= MERGE > > > 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 use= d in > > > a standard emerge environment instead of using cross-emerge ? > >=20 > > you've lost me. when you `emerge-$CTARGET`, that package doesn't g= o > > anywhere near your ROOT=3D/ system. it's entirely contained in > > /usr/$CTARGET/. > >=20 > > when you run `crossdev $CTARGET`, it installs all the standard > > $CTARGET-xxx > > tools in /usr/bin. this isn't "polluting" the environment at all .= .. in > > fact, they're living right alongside existing tools. > >=20 > > as i pointed out elsewhere in this thread, the problem is that mult= ilib > > relies on automatic detection of the toolchain *failing* so that it= falls > > back to the native value. in other words, when you run `./configur= e > > --host=3Di686-pc-linux- gnu`, it tries to find e.g. i686-pc-linux-g= nu-ar.=20 > > it doesn't exist so the fallback is used (plain `ar`). multilib is= using > > these tuples so that the standard checks (autoconf/eclasses/etc...)= > > trigger in the right ways for the cpu/os/userland combinations. > >=20 > > since crossdev installs a full proper toolchain for the target, the= one > > multilib was using to lie now exists and its toolchain is used inst= ead. >=20 > Crossdev is "polluting the environment" in the specific case that we = are > talking about - secondary native ABIs on a multilib system. >=20 > 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. >=20 > However, an i686 crossdev on an amd64 multilib system is a fundamenta= lly > different situation. no, it is not > 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. Especial= ly > when i686-pc-linux-gnu-ar is in /usr/bin. sure, and it works just fine when you use the correct toolchain. if th= e user=20 wants to build an ABI using their default toolchain, they can pass the = right=20 ABI flag for it. but that's irrelevant to how our multilib implementation picks its fake= =20 CHOST_$ABI to take care of implementing things. if anything, the curre= nt=20 system is provably broken because the default ends up executing unquali= fied=20 `ar` and `ranlib` friends. =2Dmike --nextPart12383269.EWHRuQmbAG 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) iQIcBAABAgAGBQJTM8AoAAoJEEFjO5/oN/WBbz4P/3Mwoyk5WR+YsR+359syMGu8 /2cO5Kqp6jhd/PjNPCBNgs14AD5zAWtc8bFRxTVIHnBpfuKj242ZLABhxBIdo4nO PraSQlGnJr3apsgawINh/gcxksa6L++AJExLsPz7JIINxZv5KYWDeD1akt4tBMSH SQcdtDp3KhnyAUxBKZfXlAJ3f0bQ0YwAGZFptWHkpkf7/KGt4y97IZsf3dwauJVi Azn1yHeX0WwcTXvy9llW2k9+3eIDfUBLpf1WJsU6qw7+jf916EbHMwbVTYonmDnp EHQ8wz/8EkJSv50ezolPY8NzsL/N2O6oDViVz2wdB7ZUZmZlPa97PViyPQDtmTTD xNVcnv1oI73RKn9IyqHtjPtVNNGeuVzDgTQoteqV9X3IWjufSoy2jDX6EtTvtOKs YEh4X1P2wEzNsAEzjTpmFHThmIYWMdASI96FSLvaMtkoewaDejEJ+Ochx+qEAAZf qMRc9z7mHLrnqnZ3c8qtC1K99DoaB/CNWUUxXxJ1reGsGlmVwswXsmR6fhUoNli3 czY+NpAutdNn/3vJ3fKJHyDwHA27LiuJhZCeWUXDZZOzDjldVDzkz9tg53QbZbgk 9aOSZe1P9ZBk+bIfm+S5flCyHcrQUZa3KNjrJBg+y7H/lPq3gBMMvOGC7Nh8Xycv +gNxUFXR7BY/OzPBWhlH =dQyO -----END PGP SIGNATURE----- --nextPart12383269.EWHRuQmbAG--