Bug#664257: multiarch tuples are not documented/defined
On 21.03.2012 11:26, Goswin von Brederlow wrote:
Matthias Klose<email@example.com> 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.
Should we even have biarch in the multiarch world?
multilib libraries should continue to build.
The biarch libs and foreign libs installed through multiarch implement
the same ABI/calling convention/functionality. They are basically
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 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).
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.