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. MatthiasShould 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 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 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.