Bug#664257: multiarch tuples are not documented/defined

[Goswin von Brederlow <goswin-v-b@web.de>]

Matthias Klose <doko@debian.org> writes:

> On 19.03.2012 15:34, Jonathan Nieder wrote:
>> Goswin von Brederlow wrote:
>>
>>> Did you read the wiki page?
>>
>> Yes.  Is the kind of information on which calling convention, basic
>> system library structures, and so on form the ABI for a given tuple
>> that I was giving examples of not what the upstream gcc folks were
>> looking for?  I'm not sure I understand the point of your question.
>>
>> Ah, maybe this is where we are talking past each other: I read this as
>> a request to pin down and document the definition of each multiarch
>> tuple.  Perhaps you read it as a request to pin down and document the
>> definition of the term "multiarch tuple", without necessarily pinning
>> down the details for each arch.
>>
>> It would certainly be useful to clarify which is needed before
>> deciding which to spend time on, so thanks for asking.  Matthias?
>
> first thing would be the documentation of each tuple currently used by
> Debian (including the ones used for the non-default biarch
> multilibs). If we can come up with a definition of "multiarch tuple"
> later that's fine, but given that we did abandon the earlier approach
> I'm not sure that's possible.
>
>   Matthias

Should we even have biarch in the multiarch world?

The biarch libs and foreign libs installed through multiarch implement
the same ABI/calling convention/functionality. They are basically
interchangable.

To make them truely interchangable the multiarch tuple for biarch libs
should be the same as they would have if they were the native
one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as
example from now on]. And they should use the same paths. If there is no
native equivalent for some biarch lib then just make up some multiarch
tuple based on the gnu triplet. The only thing that matters is that it
uniquly identifies the calling convention of the lib.


For Debian (wheezy+x) I would like to see gcc-multilib depend on
libc6:i386 instead of libc6-i386. Or maybe remove multilib support
alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc
-m32 could remain for compatibility but call i486-linux-gnu-gcc.

After all with multiarch having anything build for 32bit in amd64 is
wastefull as it just duplicates the package already in i386. Same with
ppc / ppc64, ...

MfG
        Goswin