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 7ACF6138247 for ; Wed, 22 Jan 2014 14:24:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 88F86E0F16; Wed, 22 Jan 2014 14:24:57 +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 CFDCCE0F16 for ; Wed, 22 Jan 2014 14:24:56 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id C1C9033FAEC for ; Wed, 22 Jan 2014 14:24:55 +0000 (UTC) Message-ID: <52DFD4B7.8060306@gentoo.org> Date: Wed, 22 Jan 2014 09:24:55 -0500 From: "Anthony G. Basile" 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> <52D9746E.4020200@gentoo.org> <20140117195154.4b512793@pomiot.lan> <52D98807.2060201@gentoo.org> In-Reply-To: <52D98807.2060201@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: e7efcaed-5172-4434-a47b-afe92051be11 X-Archives-Hash: 02b75b265bb46d20eba5af0e9754e8f6 On 01/17/2014 02:44 PM, Markos Chandras wrote: > 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. > My concern has been departing from GNU tuple standard which makes only restricted assumptions (see below) about abi. For this, I've always referred to the GNU config project which is supposed to guess the tuple for any system you're on. So, try this ... 1) git clone git://git.sv.gnu.org/config.git 2) cd config 3) ./config.guess Here are my results (I hope this table survives email munging!) On my multilib amd64 box I get: config.guess: x86_64-unknown-linux-gnu I use: x86_64-pc-linux-gnu On my multilib o32/n32/n64 lemote yeeloong: config.guess: mips64el-unknown-linux-gnu I use: mips64el-unknown-linux-gnu On my unilib amd64 uclibc I get: config.guess: x86_64-unknown-linux-uclibc I use: x86_64-gentoo-linux-uclibc On my unilib o32 mips32r2 I get: config.guess: mips-unknown-linux-uclibc I use: mips-gentoo-linux-uclibc On my chromebook glibc/eabi/hf: config.guess: armv7l-unknown-linux-gnueabihf I use: armv7a-hardfloat-linux-gnueabi On my chromebook uclibc/eabi/hf config.guess: armv7l-unknown-linux-uclibceabihf I use: armv7a-hardfloat-linux-uclibceabi Note: 1) the second field, the so-called vendor field, is arbitrary. I like putting -gentoo- in there. 2) Only arm mixes in abi and hard/softfloat stuff. 4) The debian debate about departing from GNU tuples (aka triplets) is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664257 https://wiki.debian.org/Multiarch/Tuples https://wiki.debian.org/Multiarch/TuplesAbandoned Their reasons are different than ours. The concern was over i386/486/585/686 inconsistencies and arm hard/soft float. Regarding the later issue, gcc upstream suggested using the vendor field which is what we do for hard/soft arm. 5) My recommendation is that the safest thing is to use the vendor field since it is recognized as "arbitrary". I've been through abusing fields before, albeit in a different situation: with glibc and elf headers when we did pax marking in the elf header's e_ident[] field, bytes 14 and 15. Upstream grsec/pax developers originally used that for pax marking until Drepper decide to use those bytes for something else. On upgrading glibc, using chpax to do EI_PAX marking broke whatever it touched. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA