Bug#664257: multiarch tuples are not documented/defined
Matthias Klose <doko@debian.org> writes:
> On 21.03.2012 11:26, Goswin von Brederlow wrote:
>> 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?
>
> multilib libraries should continue to build.
Time will tell.
>> 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.
>
> no. adding cross-architecture build dependencies doesn't add to the
> build stability. The possibility to call another version or target
Nobody is talking about cross-architecture build dependencies.
As said building 32bit stuff on amd64 in the multiarch world is
pointless. The same stuff can just be gotten from i386 directly.
And if no source builds 32bit stuff on amd64 then we do not need
multilib.
And if nothing needs multilib then you do not need to build it and thus
do not need to build-depend on cross-architecture stuff to build it.
> compiler from the driver was removed upstream, so I doubt somebody
> want to re-add it again, and I won't carry this as a downstream patch
> (so please get the done in stage1 for 4.8 if you are interested in
> that).
Fair enough. Overall it would make no sense that I have to call
armel-linux-gnu-gcc to build for arm but gcc -m32 to build for i386 in a
multiarch world [again example with amd64 as native arch].
>> 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, ...
>
> yes, but you are quick to waste my own time. Patches which do not go
> upstream do require an extra maintenance effort as seen for the split
> build (gcc, gcj, ...) and the hardening patches. A lot of multilib
> packages can be dropped,
> but the ones built from gcc and glibc should continue to build.
Nobody is holding a gun to your head and forcing you to invest any
time. Although I would say dropping multilib would rather safe you a lot
of time and maintainance effort than cost you anything. And since
multilib is enabled in debian/* there is no patch that would need to go
upstream.
Wheezy+x is a long way in the future so lets just wait and see. There is
still a lot of work to do for multiarch before dropping multilib support
from gcc can even be considered. No point arguing about that now.
MfG
Goswin
Reply to: