Re: RFH: Multiarch capable toolchain as release goal

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

lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:

> On Tue, Apr 15, 2008 at 09:03:54PM +0200, Andreas Barth wrote:
>> * Goswin von Brederlow (goswin-v-b@web.de) [080415 20:34]:
>> >   Description: The toolchain should be ready to handle libraries and
>> >    include files in the multiarch locations.
>> >   Bug-Url: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369064
>> >   State: All done except for binutils. Patch exists.
>> 
>> Binutils are frozen for Lenny, so please no additional changes.
>
> I suspect by the time a fully working multiarch is done, x86 won't need
> it anymore because everything will be fully 64bit. :)

I would say we are already there big time. Users of ia32-libs do
disagree though. But the usefullness of multiarch for x86_64-linux-gnu
+ i486-linux-gnu has taken a major dive since sarge (which is a good
thing).

> Now I suppose sparc and others might still like it if they have
> performance advantages of 32bit code over 64bit code, in which case
> keeping 64bit for only those programs where the extra address space is
> worth it would be great.

s390x, sparc64, mips64, mipsel64, ppc64 all have performance hits for
64bit code so one would limit 64bit binaries to what needs the address
space.

But then there is i486-linux-gnu + i486-linux-uclibc,
x86_64-kfreebsd-gnu + x86_64-linux-gnu, arm-linux-gnu +
armel-linux-gnu, ia64-linux-gnu + i486-linux-gnu and many other
combinations.

Recently there was also renewed interest in reviving the 64bit long,
32bit pointer code generation in gcc for amd64. That way you get all
the speed benefits of the improved 64bit mode without the penalty of
double sized pointers. That could be used to slimmen programs that
don't need 64bit address space.

So, while being far less in demand, multiarch still has huge benefits.

MfG
        Goswin