[gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 797 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1547 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Anthony G. Basile]

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: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2193 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 935 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[sébastien bertoletto]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1961 bytes --]

Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Anthony G. Basile]

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: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs

[Anthony G. Basile]

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: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Anthony G. Basile]

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: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Anthony G. Basile]

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: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Matt Turner]

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.

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

On 01/17/2014 06:36 PM, Matt Turner wrote:
> 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.
> 
So if you have an eg multilib/n32 profile, and you emerge another
library (say libffi) you will only end up with n32 ABI libffi library?

-- 
Regards,
Markos Chandras

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Matt Turner]

On Fri, Jan 17, 2014 at 11:38 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> On 01/17/2014 06:36 PM, Matt Turner wrote:
>> 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.
>>
> So if you have an eg multilib/n32 profile, and you emerge another
> library (say libffi) you will only end up with n32 ABI libffi library?

It's dependent on the value of ABI_MIPS.

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

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

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Anthony G. Basile]

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 <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.
>
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

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Dnia 2014-01-22, o godz. 09:24:55
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> 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". [...]

Well, considering that it will fix the underlying issue, you have my
blessing :). If you are going to put 'gentoo' there somehow, even +2.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Markos Chandras]

On 01/22/2014 02:38 PM, Michał Górny wrote:
> Dnia 2014-01-22, o godz. 09:24:55
> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> 
>> 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". [...]
> 
> Well, considering that it will fix the underlying issue, you have my
> blessing :). If you are going to put 'gentoo' there somehow, even +2.
> 
Do you mean change the CHOST for each ABI to contain the abi name in the
vendor field? That should work...

-- 
Regards,
Markos Chandras

Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

[Anthony G. Basile]

On 01/22/2014 03:39 PM, Markos Chandras wrote:
> On 01/22/2014 02:38 PM, Michał Górny wrote:
>> Dnia 2014-01-22, o godz. 09:24:55
>> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>>
>>> 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". [...]
>> Well, considering that it will fix the underlying issue, you have my
>> blessing :). If you are going to put 'gentoo' there somehow, even +2.
>>
> Do you mean change the CHOST for each ABI to contain the abi name in the
> vendor field? That should work...
>
Yes.  Something like armv7l-hardfloat-linux-gnueabi but for mips. eg for 
big endian mips I o32 uclibc we could have mips-o32-linux-uclibc.  For 
little endian we'd have mipsel-o32-linux-uclibc.  The only thing I'm not 
sure of is how to get higher isa in there.  Maybe something like 
mips32r2-o32-linux-uclibc might work but I haven't looked at the gnu 
config stuff closely yet in this respect.  And 64-bit little endian n32 
glibc might be mips64el-n32-linux-gnu.

Also, we need to be clear what we are talking about here.  That stolen 
vendor field would just be the native abi because your compiler and 
binutils can be (for example) o32, but you can still build for n32 and 
n64 (provided your hardware can handle it).  In fact on my lemote images 
(and probably all the multilib stages but I haven't looked), all my 
toolchain binaries are n32, except glibc which in /lib is o32, in /lib32 
is n32and in /lib64 is n64 --- what abi your toolchain produces depends 
on what you pass to -mabi=.  So I'm thinking the lemote tuple would look 
like mips64el-n32-linux-gnu but this doesn't mean the toolchain can only 
build for n32.  I'm not sure if this solves mgorny's multilib issue or 
not.  But something like mips64el-o32n32n64-linux-gnu is confusing and ugly.

I'm going to miss the gentoo in there :(  But, if we stick to *just* the 
vendor field, I should be able to change over my scripts easily and with 
one catalyst run have the new CHOST.

Finally before we implement this, I'll draw up a chart.  Let's discuss 
what we want first because one catalyst run on my old ubiquity boards is 
one week of time!  I could cross compile much faster, but I like knowing 
that it works on native hardware.

-- 
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