public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
From: Markos Chandras <hwoarang@gentoo.org>
To: "Michał Górny" <mgorny@gentoo.org>, gentoo-mips@lists.gentoo.org
Subject: Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs
Date: Tue, 21 Jan 2014 20:52:10 +0000	[thread overview]
Message-ID: <52DEDDFA.9000905@gentoo.org> (raw)
In-Reply-To: <52D98807.2060201@gentoo.org>

On 01/17/2014 07: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 <hwoarang@gentoo.org> 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"
>>>> <blueness@gentoo.org> 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.
> 

fwiw i talked to Michal on IRC and promised to do some tests on my
mips64/multilib/n32 box to see what the actual problem is and if his
proposal breaks existing installations. Once I have some results, I will
reply to the list.

-- 
Regards,
Markos Chandras


  reply	other threads:[~2014-01-21 21:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-28 22:58 [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs Michał Górny
2013-12-28 23:55 ` Markos Chandras
2013-12-29  2:12 ` Mike Frysinger
     [not found]   ` <20131229163354.35b65df5@gentoo.org>
2013-12-29 18:21     ` Mike Frysinger
2013-12-30  9:44       ` Michał Górny
2013-12-29 21:40 ` [gentoo-mips] " Joshua Kinard
2013-12-29 21:48   ` Markos Chandras
2013-12-29 21:48   ` Michał Górny
2013-12-29 21:48     ` Markos Chandras
2013-12-29 21:52       ` Anthony G. Basile
2013-12-29 22:04         ` Michał Górny
2013-12-29 23:56           ` Mike Frysinger
2013-12-30  7:51             ` Mike Frysinger
2013-12-30  8:17               ` sébastien bertoletto
2013-12-29 22:13         ` Markos Chandras
2013-12-29 22:19           ` Anthony G. Basile
2013-12-29 22:33             ` Markos Chandras
2013-12-29 23:47               ` Anthony G. Basile
2014-01-16 20:01 ` [gentoo-mips] " Michał Górny
2014-01-16 21:05   ` Anthony G. Basile
2014-01-16 21:24     ` Michał Górny
2014-01-16 22:29       ` Anthony G. Basile
2014-01-17  4:47         ` Michał Górny
2014-01-17 18:20           ` Markos Chandras
2014-01-17 18:36             ` Matt Turner
2014-01-17 19:38               ` Markos Chandras
2014-01-17 21:57                 ` Matt Turner
2014-01-17 18:51             ` Michał Górny
2014-01-17 19:44               ` Markos Chandras
2014-01-21 20:52                 ` Markos Chandras [this message]
2014-01-22 14:24                 ` Anthony G. Basile
2014-01-22 14:38                   ` Michał Górny
2014-01-22 20:39                     ` Markos Chandras
2014-01-22 21:07                       ` Anthony G. Basile

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52DEDDFA.9000905@gentoo.org \
    --to=hwoarang@gentoo.org \
    --cc=gentoo-mips@lists.gentoo.org \
    --cc=mgorny@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox