Mailing List Archive

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

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

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

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.

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

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

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

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

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