public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs
  @ 2014-01-17 19:44 99%               ` Markos Chandras
  0 siblings, 0 replies; 1+ results
From: Markos Chandras @ 2014-01-17 19:44 UTC (permalink / raw
  To: Michał Górny, gentoo-mips

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.

-- 
Regards,
Markos Chandras


^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-12-28 22:58     [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs Michał Górny
2014-01-16 20:01     ` 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:51                 ` Michał Górny
2014-01-17 19:44 99%               ` Markos Chandras

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox