Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Gentoo>
  3. MIPS
1 2  View All
On MIPS using the same CHOST for all multilib ABIs
mgorny at gentoo
Dec 28, 2013, 2:58 PM
Post #1 of 34 (19500 views)
Permalink
Hello, folks.

I've noticed today that mips uses the same CHOST value for all three
ABIs it supports:

arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"

Long story short, this sucks and will cause trouble.

In the multilib stuff, we're using CHOST for two purposes:

1. wrapped headers are put in /usr/include/$CHOST,

2. multilib executables are prefixed with $CHOST-.

(1) here is not really a killer feature but I'd rather avoid changing
this at this point. (2) is actually a killer feature, since the eclass
sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can
find multilib *-config progs and stuff without any special hackery.

And those are just the examples I can think of. I suspect that more stuff
may actually expect CHOST to uniquely identify build, especially some
tricky hidden features in autotools :).

I'd suggest that you changed the CHOST values to uniquely identify ABI
in use, at least in multilib profiles and preferably in all of them.

--
Best regards,
Michał Górny

Attached Files:

Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
hwoarang at gentoo
Dec 28, 2013, 3:55 PM
Post #2 of 34 (19385 views)
Permalink
On 12/28/2013 10:58 PM, Michał Górny wrote:
> Hello, folks.
>
> I've noticed today that mips uses the same CHOST value for all three
> ABIs it supports:
>
> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>
> Long story short, this sucks and will cause trouble.
>
> In the multilib stuff, we're using CHOST for two purposes:
>
> 1. wrapped headers are put in /usr/include/$CHOST,
>
> 2. multilib executables are prefixed with $CHOST-.
>
> (1) here is not really a killer feature but I'd rather avoid changing
> this at this point. (2) is actually a killer feature, since the eclass
> sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can
> find multilib *-config progs and stuff without any special hackery.
>
> And those are just the examples I can think of. I suspect that more stuff
> may actually expect CHOST to uniquely identify build, especially some
> tricky hidden features in autotools :).
>
> I'd suggest that you changed the CHOST values to uniquely identify ABI
> in use, at least in multilib profiles and preferably in all of them.
>
(no particular answer at this point)

Just want to point out that debian uses these

mips64X-linux-gnuabin32, gnuabi64 etc.

I do see the benefits of having the default abi embedded into the CHOST
tuple but migrating to it may be quite painful.

--
Regards,
Markos Chandras
Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
vapier at gentoo
Dec 28, 2013, 6:12 PM
Post #3 of 34 (19378 views)
Permalink
On Saturday 28 December 2013 17:58:39 Michał Górny wrote:
> I've noticed today that mips uses the same CHOST value for all three
> ABIs it supports:

mips isn't the only one

> 1. wrapped headers are put in /usr/include/$CHOST,

then you're doing it wrong. you cannot assume CHOST uniqueness.

> 2. multilib executables are prefixed with $CHOST-.

most multilib packages shouldn't be installing more than one binary in the
first place

> (1) here is not really a killer feature but I'd rather avoid changing
> this at this point. (2) is actually a killer feature, since the eclass
> sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can
> find multilib *-config progs and stuff without any special hackery.

*-config progs are dead. use pkg-config.
-mike

Attached Files:

Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
vapier at gentoo
Dec 29, 2013, 10:21 AM
Post #4 of 34 (19385 views)
Permalink
On Sunday 29 December 2013 10:33:54 Alexis Ballier wrote:
> On Sat, 28 Dec 2013 21:12:53 -0500 Mike Frysinger wrote:
> > you cannot assume CHOST uniqueness.
>
> why ? I was under the impression that a CHOST entirely defines an ABI

that has never been the case. a CHOST defines a unique toolchain, not a unique
ABI. a toolchain may support more than one ABI (and frequently does).

we've run into issues in the past where people install a toolchain via
crossdev that uses the same tuple as the non-default ABI one (e.g. people on
an amd64 system do `crossdev i686-pc-linux-gnu`) and then the multilib code
gets confused. but it's been much more of a hassle to try and get configure
scripts to use compile tests rather than probe the CHOST, so we've just lived
with this lesser evil.

> > > (1) here is not really a killer feature but I'd rather avoid
> > > changing this at this point. (2) is actually a killer feature,
> > > since the eclass sets CHOST properly and thanks to that
> > > AC_CHECK_TOOL and friends can find multilib *-config progs and
> > > stuff without any special hackery.
> >
> > *-config progs are dead. use pkg-config.
>
> ok; but shouldnt we kill that tc-getPKG_CONFIG() which returns
> $CHOST-pkg-config then ?

i didn't mean specifically use `pkg-config`. packages should be using .pc files
instead of *-config scripts.

you're right that pkg-config is natively unaware of ABI, but the multilib
eclasses workaround that by setting PKG_CONFIG vars to the right place.
-mike

Attached Files:

Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
kumba at gentoo
Dec 29, 2013, 1:40 PM
Post #5 of 34 (19401 views)
Permalink
On 12/28/2013 5:58 PM, Michał Górny wrote:
> Hello, folks.
>
> I've noticed today that mips uses the same CHOST value for all three
> ABIs it supports:
>
> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>
> Long story short, this sucks and will cause trouble.
>
> In the multilib stuff, we're using CHOST for two purposes:
>
> 1. wrapped headers are put in /usr/include/$CHOST,
>
> 2. multilib executables are prefixed with $CHOST-.
>
> (1) here is not really a killer feature but I'd rather avoid changing
> this at this point. (2) is actually a killer feature, since the eclass
> sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can
> find multilib *-config progs and stuff without any special hackery.
>
> And those are just the examples I can think of. I suspect that more stuff
> may actually expect CHOST to uniquely identify build, especially some
> tricky hidden features in autotools :).
>
> I'd suggest that you changed the CHOST values to uniquely identify ABI
> in use, at least in multilib profiles and preferably in all of them.

Matt can probably vouch for this better, but the only two ABIs affected by
this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
big/little endian CHOST, which means the o32 ABI.
mips64[el]-unknown-linux-gnu means either n32 or n64. So no change should
be needed for o32-based installs.

According to this Debian wiki entry:
https://wiki.debian.org/Multiarch/Tuples

We would have to adopt mips64[el]-unknown-linux-gnuabin32 for n32 and
-gnuabin64 for n64. Testing would be needed to watch for packages that
don't have updated config.sub/config.guess files and fail to recognize this
particular CHOST.

--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Attached Files:

Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
hwoarang at gentoo
Dec 29, 2013, 1:48 PM
Post #6 of 34 (19392 views)
Permalink
On 12/29/2013 09:40 PM, Joshua Kinard wrote:
> On 12/28/2013 5:58 PM, Michał Górny wrote:
>> Hello, folks.
>>
>> I've noticed today that mips uses the same CHOST value for all three
>> ABIs it supports:
>>
>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>
>> Long story short, this sucks and will cause trouble.
>>
>> In the multilib stuff, we're using CHOST for two purposes:
>>
>> 1. wrapped headers are put in /usr/include/$CHOST,
>>
>> 2. multilib executables are prefixed with $CHOST-.
>>
>> (1) here is not really a killer feature but I'd rather avoid changing
>> this at this point. (2) is actually a killer feature, since the eclass
>> sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can
>> find multilib *-config progs and stuff without any special hackery.
>>
>> And those are just the examples I can think of. I suspect that more stuff
>> may actually expect CHOST to uniquely identify build, especially some
>> tricky hidden features in autotools :).
>>
>> I'd suggest that you changed the CHOST values to uniquely identify ABI
>> in use, at least in multilib profiles and preferably in all of them.
>
> Matt can probably vouch for this better, but the only two ABIs affected by
> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
> big/little endian CHOST, which means the o32 ABI.

Why? mips64 can do o32 as well.

>
> According to this Debian wiki entry:
> https://wiki.debian.org/Multiarch/Tuples

Probably because they don't do mips64/o32. But we do, so we would also
need *-linux-gnuabi32

--
Regards,
Markos Chandras
Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
mgorny at gentoo
Dec 29, 2013, 1:48 PM
Post #7 of 34 (19383 views)
Permalink
Dnia 2013-12-29, o godz. 16:40:08
Joshua Kinard <kumba@gentoo.org> napisał(a):

> On 12/28/2013 5:58 PM, Michał Górny wrote:
> > I've noticed today that mips uses the same CHOST value for all three
> > ABIs it supports:
> >
> > arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
> > arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
> > arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
> > arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
> > arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
> > arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
> >
> > [...]
>
> Matt can probably vouch for this better, but the only two ABIs affected by
> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
> big/little endian CHOST, which means the o32 ABI.
> mips64[el]-unknown-linux-gnu means either n32 or n64. So no change should
> be needed for o32-based installs.

Just to be clear:

profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:

CHOST="mips64el-unknown-linux-gnu"

[...]

CFLAGS_o32="-mabi=32"
CHOST_o32="${CHOST}"

CFLAGS_n32="-mabi=n32"
CHOST_n32="${CHOST}"

CFLAGS_n64="-mabi=64"
CHOST_n64="${CHOST}"

So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
I'm missing something.

--
Best regards,
Michał Górny

Attached Files:

Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
hwoarang at gentoo
Dec 29, 2013, 1:48 PM
Post #8 of 34 (19385 views)
Permalink
On 12/29/2013 09:48 PM, Michał Górny wrote:
> Dnia 2013-12-29, o godz. 16:40:08
> Joshua Kinard <kumba@gentoo.org> napisał(a):
>
>> On 12/28/2013 5:58 PM, Michał Górny wrote:
>>> I've noticed today that mips uses the same CHOST value for all three
>>> ABIs it supports:
>>>
>>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>>
>>> [...]
>>
>> Matt can probably vouch for this better, but the only two ABIs affected by
>> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
>> big/little endian CHOST, which means the o32 ABI.
>> mips64[el]-unknown-linux-gnu means either n32 or n64. So no change should
>> be needed for o32-based installs.
>
> Just to be clear:
>
> profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
>
> CHOST="mips64el-unknown-linux-gnu"
>
> [...]
>
> CFLAGS_o32="-mabi=32"
> CHOST_o32="${CHOST}"
>
> CFLAGS_n32="-mabi=n32"
> CHOST_n32="${CHOST}"
>
> CFLAGS_n64="-mabi=64"
> CHOST_n64="${CHOST}"
>
> So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
> I'm missing something.
>

Yes all 3 ABIs use the same tuple.

--
Regards,
Markos Chandras
Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
basile at opensource
Dec 29, 2013, 1:52 PM
Post #9 of 34 (19391 views)
Permalink
On 12/29/2013 04:48 PM, Markos Chandras wrote:
> On 12/29/2013 09:48 PM, Michał Górny wrote:
>> Dnia 2013-12-29, o godz. 16:40:08
>> Joshua Kinard <kumba@gentoo.org> napisał(a):
>>
>>> On 12/28/2013 5:58 PM, Michał Górny wrote:
>>>> I've noticed today that mips uses the same CHOST value for all three
>>>> ABIs it supports:
>>>>
>>>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>>>
>>>> [...]
>>>
>>> Matt can probably vouch for this better, but the only two ABIs affected by
>>> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
>>> big/little endian CHOST, which means the o32 ABI.
>>> mips64[el]-unknown-linux-gnu means either n32 or n64. So no change should
>>> be needed for o32-based installs.
>>
>> Just to be clear:
>>
>> profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
>>
>> CHOST="mips64el-unknown-linux-gnu"
>>
>> [...]
>>
>> CFLAGS_o32="-mabi=32"
>> CHOST_o32="${CHOST}"
>>
>> CFLAGS_n32="-mabi=n32"
>> CHOST_n32="${CHOST}"
>>
>> CFLAGS_n64="-mabi=64"
>> CHOST_n64="${CHOST}"
>>
>> So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
>> I'm missing something.
>>
>
> Yes all 3 ABIs use the same tuple.
>

I think people are missing Mike's point from earlier, which is that
tuples label toolchains and a toolchain can support multiple abis. So
for example, what would one do on a system which simultaneously has o32,
n32 and n64? -gnuabi32n32n64 looks pretty crazy.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
mgorny at gentoo
Dec 29, 2013, 2:04 PM
Post #10 of 34 (19393 views)
Permalink
Dnia 2013-12-29, o godz. 16:52:05
"Anthony G. Basile" <basile@opensource.dyc.edu> napisał(a):

> On 12/29/2013 04:48 PM, Markos Chandras wrote:
> > Yes all 3 ABIs use the same tuple.
>
> I think people are missing Mike's point from earlier, which is that
> tuples label toolchains and a toolchain can support multiple abis. So
> for example, what would one do on a system which simultaneously has o32,
> n32 and n64? -gnuabi32n32n64 looks pretty crazy.

I'd say that we shouldn't limit the concept of 'toolchain' to
specifically GNU binutils + GNU gcc. Configure scripts can require much
more tools (like assemblers, *-config tools including pkg-config)
and I doubt we should really assume they all have some magic support
for ABI switching we had taken care of.

That said, it would be actually more reasonable to have three separate
triples for those ABIs, and link them to the same application if it
supports all three ABIs. Of course, we would need to ensure that
the application actually respects the triple via which it was called.

I think that would be cleaner than explicitly overriding compiler
options, and things such as PKG_CONFIG_PATH. But I guess many people
will disagree.

--
Best regards,
Michał Górny

Attached Files:

Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
hwoarang at gentoo
Dec 29, 2013, 2:13 PM
Post #11 of 34 (19393 views)
Permalink
On 12/29/2013 09:52 PM, Anthony G. Basile wrote:
> On 12/29/2013 04:48 PM, Markos Chandras wrote:
>> On 12/29/2013 09:48 PM, Michał Górny wrote:
>>> Dnia 2013-12-29, o godz. 16:40:08
>>> Joshua Kinard <kumba@gentoo.org> napisał(a):
>>>
>>>> On 12/28/2013 5:58 PM, Michał Górny wrote:
>>>>> I've noticed today that mips uses the same CHOST value for all three
>>>>> ABIs it supports:
>>>>>
>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>>>>
>>>>> [...]
>>>>
>>>> Matt can probably vouch for this better, but the only two ABIs
>>>> affected by
>>>> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
>>>> big/little endian CHOST, which means the o32 ABI.
>>>> mips64[el]-unknown-linux-gnu means either n32 or n64. So no change
>>>> should
>>>> be needed for o32-based installs.
>>>
>>> Just to be clear:
>>>
>>> profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
>>>
>>> CHOST="mips64el-unknown-linux-gnu"
>>>
>>> [...]
>>>
>>> CFLAGS_o32="-mabi=32"
>>> CHOST_o32="${CHOST}"
>>>
>>> CFLAGS_n32="-mabi=n32"
>>> CHOST_n32="${CHOST}"
>>>
>>> CFLAGS_n64="-mabi=64"
>>> CHOST_n64="${CHOST}"
>>>
>>> So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
>>> I'm missing something.
>>>
>>
>> Yes all 3 ABIs use the same tuple.
>>
>
> I think people are missing Mike's point from earlier, which is that
> tuples label toolchains and a toolchain can support multiple abis. So
> for example, what would one do on a system which simultaneously has o32,
> n32 and n64? -gnuabi32n32n64 looks pretty crazy.
>
There is only one default ABI, so the toolchain should be named after
that. But that does not mean the toolchain can't build for different ABIs

--
Regards,
Markos Chandras
Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
blueness at gentoo
Dec 29, 2013, 2:19 PM
Post #12 of 34 (19382 views)
Permalink
On 12/29/2013 05:13 PM, Markos Chandras wrote:
> On 12/29/2013 09:52 PM, Anthony G. Basile wrote:
>> On 12/29/2013 04:48 PM, Markos Chandras wrote:
>>> On 12/29/2013 09:48 PM, Michał Górny wrote:
>>>> Dnia 2013-12-29, o godz. 16:40:08
>>>> Joshua Kinard <kumba@gentoo.org> napisał(a):
>>>>
>>>>> On 12/28/2013 5:58 PM, Michał Górny wrote:
>>>>>> I've noticed today that mips uses the same CHOST value for all three
>>>>>> ABIs it supports:
>>>>>>
>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>>>>>
>>>>>> [...]
>>>>> Matt can probably vouch for this better, but the only two ABIs
>>>>> affected by
>>>>> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
>>>>> big/little endian CHOST, which means the o32 ABI.
>>>>> mips64[el]-unknown-linux-gnu means either n32 or n64. So no change
>>>>> should
>>>>> be needed for o32-based installs.
>>>> Just to be clear:
>>>>
>>>> profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
>>>>
>>>> CHOST="mips64el-unknown-linux-gnu"
>>>>
>>>> [...]
>>>>
>>>> CFLAGS_o32="-mabi=32"
>>>> CHOST_o32="${CHOST}"
>>>>
>>>> CFLAGS_n32="-mabi=n32"
>>>> CHOST_n32="${CHOST}"
>>>>
>>>> CFLAGS_n64="-mabi=64"
>>>> CHOST_n64="${CHOST}"
>>>>
>>>> So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
>>>> I'm missing something.
>>>>
>>> Yes all 3 ABIs use the same tuple.
>>>
>> I think people are missing Mike's point from earlier, which is that
>> tuples label toolchains and a toolchain can support multiple abis. So
>> for example, what would one do on a system which simultaneously has o32,
>> n32 and n64? -gnuabi32n32n64 looks pretty crazy.
>>
> There is only one default ABI, so the toolchain should be named after
> that. But that does not mean the toolchain can't build for different ABIs
>
No because that would confuse a toolchain which only supports n32 with
one that supports o32/n32/n64. Anyhow, Michał response is heading in
the right direction where we'd have to use multiple tuple on multilib
system support more than one lib. I'm still not sure where this will
land us with respect to gnuconfig and other tuple parsing tools that
bring in their own assumptions.

--
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
Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
hwoarang at gentoo
Dec 29, 2013, 2:33 PM
Post #13 of 34 (19385 views)
Permalink
On 12/29/2013 10:19 PM, Anthony G. Basile wrote:
> On 12/29/2013 05:13 PM, Markos Chandras wrote:
>> On 12/29/2013 09:52 PM, Anthony G. Basile wrote:
>>> On 12/29/2013 04:48 PM, Markos Chandras wrote:
>>>> On 12/29/2013 09:48 PM, Michał Górny wrote:
>>>>> Dnia 2013-12-29, o godz. 16:40:08
>>>>> Joshua Kinard <kumba@gentoo.org> napisał(a):
>>>>>
>>>>>> On 12/28/2013 5:58 PM, Michał Górny wrote:
>>>>>>> I've noticed today that mips uses the same CHOST value for all three
>>>>>>> ABIs it supports:
>>>>>>>
>>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>>>>
>>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>>>>>>>
>>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>>>>>>
>>>>>>>
>>>>>>> [...]
>>>>>> Matt can probably vouch for this better, but the only two ABIs
>>>>>> affected by
>>>>>> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
>>>>>> big/little endian CHOST, which means the o32 ABI.
>>>>>> mips64[el]-unknown-linux-gnu means either n32 or n64. So no change
>>>>>> should
>>>>>> be needed for o32-based installs.
>>>>> Just to be clear:
>>>>>
>>>>> profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
>>>>>
>>>>> CHOST="mips64el-unknown-linux-gnu"
>>>>>
>>>>> [...]
>>>>>
>>>>> CFLAGS_o32="-mabi=32"
>>>>> CHOST_o32="${CHOST}"
>>>>>
>>>>> CFLAGS_n32="-mabi=n32"
>>>>> CHOST_n32="${CHOST}"
>>>>>
>>>>> CFLAGS_n64="-mabi=64"
>>>>> CHOST_n64="${CHOST}"
>>>>>
>>>>> So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
>>>>> I'm missing something.
>>>>>
>>>> Yes all 3 ABIs use the same tuple.
>>>>
>>> I think people are missing Mike's point from earlier, which is that
>>> tuples label toolchains and a toolchain can support multiple abis. So
>>> for example, what would one do on a system which simultaneously has o32,
>>> n32 and n64? -gnuabi32n32n64 looks pretty crazy.
>>>
>> There is only one default ABI, so the toolchain should be named after
>> that. But that does not mean the toolchain can't build for different ABIs
>>
> No because that would confuse a toolchain which only supports n32 with
> one that supports o32/n32/n64.
Ah fair point

Anyhow, Michał response is heading in
> the right direction where we'd have to use multiple tuple on multilib
> system support more than one lib. I'm still not sure where this will
> land us with respect to gnuconfig and other tuple parsing tools that
> bring in their own assumptions.
>
I would guess that if debian is using the -gnuabin32/64 suffix and it
works for them, then such tools would already understand such tuples.

--
Regards,
Markos Chandras
Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
blueness at gentoo
Dec 29, 2013, 3:47 PM
Post #14 of 34 (19396 views)
Permalink
On 12/29/2013 05:33 PM, Markos Chandras wrote:
> On 12/29/2013 10:19 PM, Anthony G. Basile wrote:
>> On 12/29/2013 05:13 PM, Markos Chandras wrote:
>>> On 12/29/2013 09:52 PM, Anthony G. Basile wrote:
>>>> On 12/29/2013 04:48 PM, Markos Chandras wrote:
>>>>> On 12/29/2013 09:48 PM, Michał Górny wrote:
>>>>>> Dnia 2013-12-29, o godz. 16:40:08
>>>>>> Joshua Kinard <kumba@gentoo.org> napisał(a):
>>>>>>
>>>>>>> On 12/28/2013 5:58 PM, Michał Górny wrote:
>>>>>>>> I've noticed today that mips uses the same CHOST value for all three
>>>>>>>> ABIs it supports:
>>>>>>>>
>>>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
>>>>>>>> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
>>>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
>>>>>>>>
>>>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
>>>>>>>>
>>>>>>>> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
>>>>>>>>
>>>>>>>>
>>>>>>>> [...]
>>>>>>> Matt can probably vouch for this better, but the only two ABIs
>>>>>>> affected by
>>>>>>> this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
>>>>>>> big/little endian CHOST, which means the o32 ABI.
>>>>>>> mips64[el]-unknown-linux-gnu means either n32 or n64. So no change
>>>>>>> should
>>>>>>> be needed for o32-based installs.
>>>>>> Just to be clear:
>>>>>>
>>>>>> profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
>>>>>>
>>>>>> CHOST="mips64el-unknown-linux-gnu"
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>> CFLAGS_o32="-mabi=32"
>>>>>> CHOST_o32="${CHOST}"
>>>>>>
>>>>>> CFLAGS_n32="-mabi=n32"
>>>>>> CHOST_n32="${CHOST}"
>>>>>>
>>>>>> CFLAGS_n64="-mabi=64"
>>>>>> CHOST_n64="${CHOST}"
>>>>>>
>>>>>> So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
>>>>>> I'm missing something.
>>>>>>
>>>>> Yes all 3 ABIs use the same tuple.
>>>>>
>>>> I think people are missing Mike's point from earlier, which is that
>>>> tuples label toolchains and a toolchain can support multiple abis. So
>>>> for example, what would one do on a system which simultaneously has o32,
>>>> n32 and n64? -gnuabi32n32n64 looks pretty crazy.
>>>>
>>> There is only one default ABI, so the toolchain should be named after
>>> that. But that does not mean the toolchain can't build for different ABIs
>>>
>> No because that would confuse a toolchain which only supports n32 with
>> one that supports o32/n32/n64.
> Ah fair point
>
> Anyhow, Michał response is heading in
>> the right direction where we'd have to use multiple tuple on multilib
>> system support more than one lib. I'm still not sure where this will
>> land us with respect to gnuconfig and other tuple parsing tools that
>> bring in their own assumptions.
>>
> I would guess that if debian is using the -gnuabin32/64 suffix and it
> works for them, then such tools would already understand such tuples.
>
Or their maintaining lots-o-patches which is what starts to happen when
you deviate from standards. Anyhow, we should talk to them and see.

--
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
Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
vapier at gentoo
Dec 29, 2013, 3:56 PM
Post #15 of 34 (19390 views)
Permalink
On Sunday 29 December 2013 17:04:34 Michał Górny wrote:
> Dnia 2013-12-29, o godz. 16:52:05 "Anthony G. Basile" napisał(a):
> > On 12/29/2013 04:48 PM, Markos Chandras wrote:
> > > Yes all 3 ABIs use the same tuple.
> >
> > I think people are missing Mike's point from earlier, which is that
> > tuples label toolchains and a toolchain can support multiple abis. So
> > for example, what would one do on a system which simultaneously has o32,
> > n32 and n64? -gnuabi32n32n64 looks pretty crazy.
>
> I'd say that we shouldn't limit the concept of 'toolchain' to
> specifically GNU binutils + GNU gcc. Configure scripts can require much
> more tools (like assemblers, *-config tools including pkg-config)
> and I doubt we should really assume they all have some magic support
> for ABI switching we had taken care of.

the problem you pointed out is a limitation in our code: we cannot assume
CHOST is unique for an ABI, thus using that as a unique path in generating ABI
headers is wrong. conflating that bug in our code with any other issue is
wrong. you can easily use ${CHOST}/${ABI} or ${CHOST}-${ABI} or just ${ABI}
(since /usr/include is already associated with ${CHOST}).

when it comes to *-config tools, those are known to be old and crap (for many
more reasons than just multilib/cross-compiling). convert to .pc files and use
pkg-config instead.

> That said, it would be actually more reasonable to have three separate
> triples for those ABIs, and link them to the same application if it
> supports all three ABIs. Of course, we would need to ensure that
> the application actually respects the triple via which it was called.

creating a unique tuple is feasible via the vendor field as a last resort.
however, unless you have a compelling reason to do so, i don't think it makes
sense to pursue it. other than the vendor field, we are limited by what
upstream GNU does and in that regard, they haven't always used unique tuples
for ABI selection (this isn't limited to MIPS either).

so to turn your base argument around, we shouldn't be limiting Gentoo to only
support CHOSTs that also select ABIs uniquely.
-mike

Attached Files:

Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
vapier at gentoo
Dec 29, 2013, 11:51 PM
Post #16 of 34 (19380 views)
Permalink
On Sunday 29 December 2013 18:56:14 Mike Frysinger wrote:
> so to turn your base argument around, we shouldn't be limiting Gentoo to
> only support CHOSTs that also select ABIs uniquely.

also worth noting: we've been severely limiting ourselves as to the full range
of possibilities. when we say "ABI", we've largely been focusing on the most
common aspect. in reality, an ABI is defined by many more features like:
- endian (little/big)
- floating point (hard/soft/etc...)
- ISA selection (mips1/mips2/mips3/mips4/... or i386/i486/i586/i686/... or
sse1/sse2/mmx/3dnow!/...)
there are other aspects too, but these are the obvious ones that people are
selecting every day. people have one toolchain which can generate code for
all of these things merely by flag selection, not different CHOST values. in
Gentoo we don't commonly support this as most people don't care, but it has
been done before.
-mike

Attached Files:

Re: Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
sbertoletto at gmail
Dec 30, 2013, 12:17 AM
Post #17 of 34 (19385 views)
Permalink
Hello,

Please delete me from the list : *lists.gentoo.org
<http://lists.gentoo.org>*

Thanks,


2013/12/30 Mike Frysinger <vapier@gentoo.org>

> On Sunday 29 December 2013 18:56:14 Mike Frysinger wrote:
> > so to turn your base argument around, we shouldn't be limiting Gentoo to
> > only support CHOSTs that also select ABIs uniquely.
>
> also worth noting: we've been severely limiting ourselves as to the full
> range
> of possibilities. when we say "ABI", we've largely been focusing on the
> most
> common aspect. in reality, an ABI is defined by many more features like:
> - endian (little/big)
> - floating point (hard/soft/etc...)
> - ISA selection (mips1/mips2/mips3/mips4/... or i386/i486/i586/i686/... or
> sse1/sse2/mmx/3dnow!/...)
> there are other aspects too, but these are the obvious ones that people are
> selecting every day. people have one toolchain which can generate code for
> all of these things merely by flag selection, not different CHOST values.
> in
> Gentoo we don't commonly support this as most people don't care, but it has
> been done before.
> -mike
>



--
Sébastien Bertoletto
Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
mgorny at gentoo
Dec 30, 2013, 1:44 AM
Post #18 of 34 (19382 views)
Permalink
Dnia 2013-12-29, o godz. 13:21:21
Mike Frysinger <vapier@gentoo.org> napisał(a):

> we've run into issues in the past where people install a toolchain via
> crossdev that uses the same tuple as the non-default ABI one (e.g. people on
> an amd64 system do `crossdev i686-pc-linux-gnu`) and then the multilib code
> gets confused. but it's been much more of a hassle to try and get configure
> scripts to use compile tests rather than probe the CHOST, so we've just lived
> with this lesser evil.

Out of curiosity, does a dedicated i686 toolchain on a multilib amd64
host have any benefits over the toolchain's -m32 options? Well, except
for not needing the explicit options.


> > > > (1) here is not really a killer feature but I'd rather avoid
> > > > changing this at this point. (2) is actually a killer feature,
> > > > since the eclass sets CHOST properly and thanks to that
> > > > AC_CHECK_TOOL and friends can find multilib *-config progs and
> > > > stuff without any special hackery.
> > >
> > > *-config progs are dead. use pkg-config.
> >
> > ok; but shouldnt we kill that tc-getPKG_CONFIG() which returns
> > $CHOST-pkg-config then ?
>
> i didn't mean specifically use `pkg-config`. packages should be using .pc files
> instead of *-config scripts.

'Should' is far away from reality. I'd rather avoid Gentoo inventing
pkg-config files for random packages where upstream simply refuses to
do that.

Then, there's LLVM. Their llvm-config has some more options than
pkg-config does, and it supports selecting single components. If we're
to do something semi-equal to that, we'd end up with 116 pkg-config
files, plus around 23 for clang. And each new supported target
increases that number by 5-7 files.

Of course, we could put them all in a single file.. but then we're
replacing one crap with another. And forcing the --as-needed hack
on top of it.

--
Best regards,
Michał Górny

Attached Files:

Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
mgorny at gentoo
Jan 16, 2014, 12:01 PM
Post #19 of 34 (19312 views)
Permalink
Dnia 2013-12-28, o godz. 23:58:39
Michał Górny <mgorny@gentoo.org> napisał(a):

> In the multilib stuff, we're using CHOST for two purposes:
>
> 1. wrapped headers are put in /usr/include/$CHOST,
>
> 2. multilib executables are prefixed with $CHOST-.
>
> (...)
>
> I'd suggest that you changed the CHOST values to uniquely identify ABI
> in use, at least in multilib profiles and preferably in all of them.

Ping. The discussion seems stalled while we're hitting increasing
number of packages that rely on CHOST to run *-config programs. My main
is that AFAICS this is the only upstream-compatible way of handling
this without hackery on our side.

As far as I understand, if you changed the CHOSTs only for non-native
ABIs (and therefore leaving the prefix used for toolchain unchanged)
the risk should be minimal.

--
Best regards,
Michał Górny

Attached Files:

Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
basile at opensource
Jan 16, 2014, 1:05 PM
Post #20 of 34 (19320 views)
Permalink
On 01/16/2014 03:01 PM, Michał Górny wrote:
> Dnia 2013-12-28, o godz. 23:58:39
> Michał Górny <mgorny@gentoo.org> napisał(a):
>
>> In the multilib stuff, we're using CHOST for two purposes:
>>
>> 1. wrapped headers are put in /usr/include/$CHOST,
>>
>> 2. multilib executables are prefixed with $CHOST-.
>>
>> (...)
>>
>> I'd suggest that you changed the CHOST values to uniquely identify ABI
>> in use, at least in multilib profiles and preferably in all of them.
>
> Ping. The discussion seems stalled while we're hitting increasing
> number of packages that rely on CHOST to run *-config programs. My main
> is that AFAICS this is the only upstream-compatible way of handling
> this without hackery on our side.
>
> As far as I understand, if you changed the CHOSTs only for non-native
> ABIs (and therefore leaving the prefix used for toolchain unchanged)
> the risk should be minimal.
>

Mike suggested creating another variable which was a combination of
CHOST and ABI for the multilib stuff. Why can't you pursue that approach?

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
mgorny at gentoo
Jan 16, 2014, 1:24 PM
Post #21 of 34 (19302 views)
Permalink
Dnia 2014-01-16, o godz. 16:05:24
"Anthony G. Basile" <basile@opensource.dyc.edu> napisał(a):

> On 01/16/2014 03:01 PM, Michał Górny wrote:
> > Dnia 2013-12-28, o godz. 23:58:39
> > Michał Górny <mgorny@gentoo.org> napisał(a):
> >
> >> In the multilib stuff, we're using CHOST for two purposes:
> >>
> >> 1. wrapped headers are put in /usr/include/$CHOST,
> >>
> >> 2. multilib executables are prefixed with $CHOST-.
> >>
> >> (...)
> >>
> >> I'd suggest that you changed the CHOST values to uniquely identify ABI
> >> in use, at least in multilib profiles and preferably in all of them.
> >
> > Ping. The discussion seems stalled while we're hitting increasing
> > number of packages that rely on CHOST to run *-config programs. My main
> > is that AFAICS this is the only upstream-compatible way of handling
> > this without hackery on our side.
> >
> > As far as I understand, if you changed the CHOSTs only for non-native
> > ABIs (and therefore leaving the prefix used for toolchain unchanged)
> > the risk should be minimal.
> >
>
> Mike suggested creating another variable which was a combination of
> CHOST and ABI for the multilib stuff. Why can't you pursue that approach?

Because AC_PATH_TOOL uses CHOST and some random Gentoo invention.

--
Best regards,
Michał Górny

Attached Files:

Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
blueness at gentoo
Jan 16, 2014, 2:29 PM
Post #22 of 34 (19309 views)
Permalink
On 01/16/2014 04:24 PM, Michał Górny wrote:
> Dnia 2014-01-16, o godz. 16:05:24
> "Anthony G. Basile" <basile@opensource.dyc.edu> napisał(a):
>
>> On 01/16/2014 03:01 PM, Michał Górny wrote:
>>> Dnia 2013-12-28, o godz. 23:58:39
>>> Michał Górny <mgorny@gentoo.org> napisał(a):
>>>
>>>> In the multilib stuff, we're using CHOST for two purposes:
>>>>
>>>> 1. wrapped headers are put in /usr/include/$CHOST,
>>>>
>>>> 2. multilib executables are prefixed with $CHOST-.
>>>>
>>>> (...)
>>>>
>>>> I'd suggest that you changed the CHOST values to uniquely identify ABI
>>>> in use, at least in multilib profiles and preferably in all of them.
>>> Ping. The discussion seems stalled while we're hitting increasing
>>> number of packages that rely on CHOST to run *-config programs. My main
>>> is that AFAICS this is the only upstream-compatible way of handling
>>> this without hackery on our side.
>>>
>>> As far as I understand, if you changed the CHOSTs only for non-native
>>> ABIs (and therefore leaving the prefix used for toolchain unchanged)
>>> the risk should be minimal.
>>>
>> Mike suggested creating another variable which was a combination of
>> CHOST and ABI for the multilib stuff. Why can't you pursue that approach?
> 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.

--
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
Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
mgorny at gentoo
Jan 16, 2014, 8:47 PM
Post #23 of 34 (19328 views)
Permalink
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.

--
Best regards,
Michał Górny

Attached Files:

Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
hwoarang at gentoo
Jan 17, 2014, 10:20 AM
Post #24 of 34 (19290 views)
Permalink
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.

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
Re: On MIPS using the same CHOST for all multilib ABIs [ In reply to ]
mattst88 at gentoo
Jan 17, 2014, 10:36 AM
Post #25 of 34 (19303 views)
Permalink
On Fri, Jan 17, 2014 at 10:20 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> 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?

The multilib profiles only *enable* multilib support by forcing on the
multilib USE flag for gcc and glibc. Without it, your system will not
have a C library built for non-default ABIs.
1 2  View All

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal