| 1 |
On 01/17/2014 02:44 PM, Markos Chandras wrote: |
| 2 |
> On 01/17/2014 06:51 PM, Michał Górny wrote: |
| 3 |
>> Dnia 2014-01-17, o godz. 18:20:30 |
| 4 |
>> Markos Chandras <hwoarang@g.o> napisał(a): |
| 5 |
>> |
| 6 |
>>> On 01/17/2014 04:47 AM, Michał Górny wrote: |
| 7 |
>>>> Dnia 2014-01-16, o godz. 17:29:43 "Anthony G. Basile" |
| 8 |
>>>> <blueness@g.o> napisał(a): |
| 9 |
>>>> |
| 10 |
>>>>> On 01/16/2014 04:24 PM, Michał Górny wrote: |
| 11 |
>>>>>> Because AC_PATH_TOOL uses CHOST and some random Gentoo |
| 12 |
>>>>>> invention. |
| 13 |
>>>>> I got that AC_PATH_TOOL and AC_CHECK_TOOL prefix whatever utility |
| 14 |
>>>>> they search for with the canonicalized chost (usually from |
| 15 |
>>>>> config.guess), but I still don't see why we need this to avoid |
| 16 |
>>>>> hackery? Can you give me a practial example because right now I |
| 17 |
>>>>> just don't see a serious problem. |
| 18 |
>>>> libgpg-error installs ${CHOST}-gpg-error-config. |
| 19 |
>>>> |
| 20 |
>>>> Now libgcrypt (and possibly other tools) are using AC_PATH_TOOL to |
| 21 |
>>>> find it. If we have proper CHOSTs, they find the right |
| 22 |
>>>> gpg-error-config and we don't have to put any more effort into |
| 23 |
>>>> that. Then libgcrypt installs ${CHOST}-libgcrypt-config. |
| 24 |
>>>> |
| 25 |
>>>> Now other tools are using AC_PATH_TOOL to find proper |
| 26 |
>>>> libgcrypt-config. If we have proper CHOSTs, it just works and we |
| 27 |
>>>> don't have to put any more effort into that. |
| 28 |
>>>> |
| 29 |
>>>> Same goes for LLVM & Mesa. |
| 30 |
>>>> |
| 31 |
>>>> If we play by the rules nicely, all pieces fit together nicely and |
| 32 |
>>>> we don't have to worry. If we don't, we ask the developers to spit |
| 33 |
>>>> Gentoo- specific hackery all over the place. |
| 34 |
>>>> |
| 35 |
>>> You need to consider that besides changing CHOST to new stages (which |
| 36 |
>>> is a lengthy and tiring process), you somehow need to migrate existing |
| 37 |
>>> users to the new CHOST (no?) otherwise the multilib eclass (or any |
| 38 |
>>> other eclass/package) that depends on CHOST will be broken as soon as |
| 39 |
>>> they update their tree and try to install package updates. |
| 40 |
>>> This is definitely not a pleasant user experience. |
| 41 |
>> Well, I'd like someone who knows better than I do to explain how much |
| 42 |
>> does changing non-native CHOST affect. I will try to test it a bit by |
| 43 |
>> changing CHOST_x86=i686-pc-linux-gnu to i386-* locally but an expert |
| 44 |
>> opinion would be preferred. |
| 45 |
>> |
| 46 |
> My comment was not on what side-effects changing the CHOST may have, but |
| 47 |
> it requires time and effort for every MIPS user out there. You also need |
| 48 |
> to consider that many people have relatively slow MIPS hardware (routers |
| 49 |
> and stuff) that will take a good couple of days (if not more) to switch |
| 50 |
> to a new CHOST. But still, not everyone is going to do it and forcing |
| 51 |
> them is definitely unpleasant. |
| 52 |
> |
| 53 |
My concern has been departing from GNU tuple standard which makes only |
| 54 |
restricted assumptions (see below) about abi. For this, I've always |
| 55 |
referred to the GNU config project which is supposed to guess the tuple |
| 56 |
for any system you're on. So, try this ... |
| 57 |
|
| 58 |
1) git clone git://git.sv.gnu.org/config.git |
| 59 |
|
| 60 |
2) cd config |
| 61 |
|
| 62 |
3) ./config.guess |
| 63 |
|
| 64 |
Here are my results (I hope this table survives email munging!) |
| 65 |
|
| 66 |
|
| 67 |
|
| 68 |
On my multilib amd64 box I get: |
| 69 |
config.guess: x86_64-unknown-linux-gnu |
| 70 |
I use: x86_64-pc-linux-gnu |
| 71 |
|
| 72 |
On my multilib o32/n32/n64 lemote yeeloong: |
| 73 |
config.guess: mips64el-unknown-linux-gnu |
| 74 |
I use: mips64el-unknown-linux-gnu |
| 75 |
|
| 76 |
On my unilib amd64 uclibc I get: |
| 77 |
config.guess: x86_64-unknown-linux-uclibc |
| 78 |
I use: x86_64-gentoo-linux-uclibc |
| 79 |
|
| 80 |
On my unilib o32 mips32r2 I get: |
| 81 |
config.guess: mips-unknown-linux-uclibc |
| 82 |
I use: mips-gentoo-linux-uclibc |
| 83 |
|
| 84 |
On my chromebook glibc/eabi/hf: |
| 85 |
config.guess: armv7l-unknown-linux-gnueabihf |
| 86 |
I use: armv7a-hardfloat-linux-gnueabi |
| 87 |
|
| 88 |
On my chromebook uclibc/eabi/hf |
| 89 |
config.guess: armv7l-unknown-linux-uclibceabihf |
| 90 |
I use: armv7a-hardfloat-linux-uclibceabi |
| 91 |
|
| 92 |
|
| 93 |
Note: 1) the second field, the so-called vendor field, is arbitrary. I |
| 94 |
like putting -gentoo- in there. 2) Only arm mixes in abi and |
| 95 |
hard/softfloat stuff. |
| 96 |
|
| 97 |
4) The debian debate about departing from GNU tuples (aka triplets) is here: |
| 98 |
|
| 99 |
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664257 |
| 100 |
https://wiki.debian.org/Multiarch/Tuples |
| 101 |
https://wiki.debian.org/Multiarch/TuplesAbandoned |
| 102 |
|
| 103 |
Their reasons are different than ours. The concern was over |
| 104 |
i386/486/585/686 inconsistencies and arm hard/soft float. Regarding the |
| 105 |
later issue, gcc upstream suggested using the vendor field which is what |
| 106 |
we do for hard/soft arm. |
| 107 |
|
| 108 |
5) My recommendation is that the safest thing is to use the vendor field |
| 109 |
since it is recognized as "arbitrary". I've been through abusing fields |
| 110 |
before, albeit in a different situation: with glibc and elf headers when |
| 111 |
we did pax marking in the elf header's e_ident[] field, bytes 14 and |
| 112 |
15. Upstream grsec/pax developers originally used that for pax marking |
| 113 |
until Drepper decide to use those bytes for something else. On |
| 114 |
upgrading glibc, using chpax to do EI_PAX marking broke whatever it touched. |
| 115 |
|
| 116 |
-- |
| 117 |
Anthony G. Basile, Ph.D. |
| 118 |
Gentoo Linux Developer [Hardened] |
| 119 |
E-Mail : blueness@g.o |
| 120 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 121 |
GnuPG ID : F52D4BBA |
Archives