[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: