On Mon, 2004-03-01 at 09:25, Ben Collins wrote: > On Mon, Mar 01, 2004 at 09:28:51AM -0500, Albert Cahalan wrote:
>> you've forced developers >> to add special Makefile hacks to support you. >> >> There is a 90% fix that won't touch the ABI at all: >> >> 1. make -m64 the default, as x86-64 does > > x86-64 runs faster and better as 64-bit. ultrasparc does not. > It's only pertinent to situations where you need to: > > a) Access more than 4gigs of ram in a single program (like a database) If you allocate anywhere near this, like 1 GB for example, you'd be better off with 64-bit. Address space allocations go slower when your address space is getting fragmented and full. They might even fail from fragmentation. > b) Access parts of the kernel internals that are not best accessed as > 32-bit translations (e.g. bridge-utils and procps). c) handle large files using the traditional API d) efficiently do math on large numbers, either directly with "long long" or with a bignum lib e) not have two C libraries resident in memory >> 2. have the install program detect ELF32 or ELF64 > > That's a pain in the ass. Huh? OK, in "install" itself, it's a pain in the ass. For all the other apps (count SourceForge projects alone) a pain-in-the-ass support issue goes away. Prior to /lib64, the most arch-specific thing in my Makefile was a "-fpic" that half the ports don't need. It was all clean and simple: no "./configure", no libtool, no auto*, and no shell hacks. > Plus if things start being built as 64-bit by > default for debian-sparc, then sparc32 users are gone. If having a 32-bit build machine is not practical, then a chroot() environment can be used for 32-bit builds. It's cross-compiling for a different arch. (while procps does fully support cross-compiling by setting variables on the "make" command line, you'd better do a chroot when dealing with many thousands of different packages)
