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 92C41138247 for ; Fri, 17 Jan 2014 19:44:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5334FE0AF5; Fri, 17 Jan 2014 19:44:51 +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 C9528E0AF5 for ; Fri, 17 Jan 2014 19:44:50 +0000 (UTC) Received: from [192.168.1.2] (unknown [176.253.35.181]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hwoarang) by smtp.gentoo.org (Postfix) with ESMTPSA id 433DA33F732; Fri, 17 Jan 2014 19:44:49 +0000 (UTC) Message-ID: <52D98807.2060201@gentoo.org> Date: Fri, 17 Jan 2014 19:44:07 +0000 From: Markos Chandras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-mips@lists.gentoo.org Reply-to: gentoo-mips@lists.gentoo.org MIME-Version: 1.0 To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , gentoo-mips@lists.gentoo.org Subject: Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs References: <20131228235839.5bb0305a@gentoo.org> <20140116210119.421c952c@pomiot.lan> <52D84994.3070306@opensource.dyc.edu> <20140116222418.6229a1b0@pomiot.lan> <52D85D57.9010500@gentoo.org> <20140117054718.5f948b88@pomiot.lan> <52D9746E.4020200@gentoo.org> <20140117195154.4b512793@pomiot.lan> In-Reply-To: <20140117195154.4b512793@pomiot.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 9d04daa6-1310-4c3d-9af7-d89c75961eff X-Archives-Hash: 1150a74b03c07f5e0018bfa75c46554a On 01/17/2014 06:51 PM, Michał Górny wrote: > Dnia 2014-01-17, o godz. 18:20:30 > Markos Chandras napisał(a): > >> On 01/17/2014 04:47 AM, Michał Górny wrote: >>> Dnia 2014-01-16, o godz. 17:29:43 "Anthony G. Basile" >>> napisał(a): >>> >>>> On 01/16/2014 04:24 PM, Michał Górny wrote: >>>>> Because AC_PATH_TOOL uses CHOST and some random Gentoo >>>>> invention. >>>> >>>> I got that AC_PATH_TOOL and AC_CHECK_TOOL prefix whatever utility >>>> they search for with the canonicalized chost (usually from >>>> config.guess), but I still don't see why we need this to avoid >>>> hackery? Can you give me a practial example because right now I >>>> just don't see a serious problem. >>> >>> libgpg-error installs ${CHOST}-gpg-error-config. >>> >>> Now libgcrypt (and possibly other tools) are using AC_PATH_TOOL to >>> find it. If we have proper CHOSTs, they find the right >>> gpg-error-config and we don't have to put any more effort into >>> that. Then libgcrypt installs ${CHOST}-libgcrypt-config. >>> >>> Now other tools are using AC_PATH_TOOL to find proper >>> libgcrypt-config. If we have proper CHOSTs, it just works and we >>> don't have to put any more effort into that. >>> >>> Same goes for LLVM & Mesa. >>> >>> If we play by the rules nicely, all pieces fit together nicely and >>> we don't have to worry. If we don't, we ask the developers to spit >>> Gentoo- specific hackery all over the place. >>> >> You need to consider that besides changing CHOST to new stages (which >> is a lengthy and tiring process), you somehow need to migrate existing >> users to the new CHOST (no?) otherwise the multilib eclass (or any >> other eclass/package) that depends on CHOST will be broken as soon as >> they update their tree and try to install package updates. >> This is definitely not a pleasant user experience. > > Well, I'd like someone who knows better than I do to explain how much > does changing non-native CHOST affect. I will try to test it a bit by > changing CHOST_x86=i686-pc-linux-gnu to i386-* locally but an expert > opinion would be preferred. > My comment was not on what side-effects changing the CHOST may have, but it requires time and effort for every MIPS user out there. You also need to consider that many people have relatively slow MIPS hardware (routers and stuff) that will take a good couple of days (if not more) to switch to a new CHOST. But still, not everyone is going to do it and forcing them is definitely unpleasant. -- Regards, Markos Chandras