Re: procps doesn't buildd - /lib versus /lib64
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)
Reply to: