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 D5F8A138247 for ; Fri, 17 Jan 2014 18:21:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9AF86E0B1B; Fri, 17 Jan 2014 18:21:13 +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 187BEE0B1B for ; Fri, 17 Jan 2014 18:21:13 +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 086C533F8C3 for ; Fri, 17 Jan 2014 18:21:11 +0000 (UTC) Message-ID: <52D9746E.4020200@gentoo.org> Date: Fri, 17 Jan 2014 18:20:30 +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: 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> In-Reply-To: <20140117054718.5f948b88@pomiot.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: e1640d40-f01f-4417-b5d5-bacf023f8bae X-Archives-Hash: 9ab4ea54752f25824d82a31318e4f7ea 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. Apologies for the stupid question (still trying to understand how our multilib works) but if our CHOST are being a problem, how come our multilib profiles work fine? -- Regards, Markos Chandras