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 5B89F13877A for ; Mon, 16 Jun 2014 20:24:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 401D9E07E1; Mon, 16 Jun 2014 20:24:48 +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 34135E0F1B for ; Mon, 16 Jun 2014 20:24:47 +0000 (UTC) Received: from 127.0.0.1 (tor20.anonymizer.ccc.de [31.172.30.3]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id D3B4B33FE25 for ; Mon, 16 Jun 2014 20:24:45 +0000 (UTC) Message-ID: <539F5288.1000000@gentoo.org> Date: Mon, 16 Jun 2014 20:24:40 +0000 From: hasufell 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference References: <53208139.2040509@gentoo.org> <1660834.UE1ARX9orZ@vapier> <20140327084108.GA3654@rathaus.eclipse.co.uk> <31757180.gTPZtqku3h@vapier> <20140330095348.GA18419@rathaus.eclipse.co.uk> <539E03A9.3010109@gentoo.org> <539E0563.3080302@gentoo.org> <539EF323.7020208@gentoo.org> <1402944163.8309.2.camel@oswin.hackershack.net> <539F462E.6050905@gentoo.org> <20140616214257.096c93fc@marga.jer-c2.orkz.net> <539F49C2.6090008@gentoo.org> <539F4DFA.7020706@gentoo.org> In-Reply-To: <539F4DFA.7020706@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: ff23f695-e711-46e4-9b9c-11f8432d0efa X-Archives-Hash: ea4c90c8306327b45ac1097759380d5e Joshua Kinard: > On 06/16/2014 15:47, hasufell wrote: >> Jeroen Roovers: >>> On Mon, 16 Jun 2014 19:31:58 +0000 >>> hasufell wrote: >>> >>>> Also check the history of this thread for a few proposed solutions. >>> >>> The history of this thread and the history of gx86-multilib and >>> crossdev development suggest that crossdev was doing nothing wrong until >>> gx86-multilib came around and a problem was found between them. Masking >>> either for the benefit of the other would be, and let me quote the >>> history of this thread out of context just to fit in with the tone and >>> mode this sub-thread has taken, "asinine". >>> >> >> This isn't about right or wrong. This is about actual breakage on stable >> systems. >> >> Solutions were proposed, nothing has happened for months. >> >> So I don't see what else we can do here other than taking more radical >> steps to INFORM users of these possible breakages... and that's exactly >> what a hardmask is for. > > What about those of us who have been using crossdev to generate > cross-compilers for years w/o issue, because we run non-multilib? > Hardmasking crossdev to solve multilib problems doesn't accomplish anything, > other than just irk us. Why not hardmask the multilib stuff instead and > leave crossdev alone? > Hardmask half of the tree instead of a single package? Does not sound reasonable. The fallout will be _huge_ for users who already run multilib. You will basically get an emerge dump of 500+ blockers. > > If so, is it sensible to allow crossdev to install a cross-toolchain when > the underlying machine architecture is the same, just a different ABI? > I.e., would a solution be to prevent i686-on-x86_64 or mips64-on-mips, but > still allow mips64-on-x86_64, and such? > That was already discussed and it will break: > yes, serving as a distcc server for x86 hosts or using 'cross emerge' > to build a x86 root from scratch