Re: procps doesn't buildd - /lib versus /lib64
On Mon, 2004-03-01 at 00:04, Ben Collins wrote:
> On Sun, Feb 29, 2004 at 11:41:18PM -0500, Albert Cahalan wrote:
> > On Sun, 2004-02-29 at 23:14, Ben Collins wrote:
> > > > > I'll consider that a wishlist. If someone gives me a patch,
> > > > > if only to set the magical gcc flags to make a 64-bit libproc,
> > > > > it will have more chance of becoming reality.
> > > >
> > > > The procps-3.2.0 code should build a 64-bit libproc
> > > > if your gcc supports -m64 and you have a 64-bit
> > > > ncurses library installed. The procps library then
> > > > goes in /lib64 if you have it, or /lib otherwise.
> > > >
> > > > All of the above is BEYOND DISGUSTING of course;
> > > > the Alpha port got this right many years ago.
> > > > The a.out-to-ELF transition was done right too.
> > > > Come on people: /usr/sparc32-linux/lib/*
> > >
> > > This isn't a transition, this is a dual installed system. 64-bit and
> > > 32-bit on a sparc64 is both sane and practical. It's not an emulation or
> > > a midway point.
> > You're rationalizing a broken design.
> > Where do you put the Solaris libs? Do likewise.
> > Running Solaris apps is equally "not an emulation".
> > Maybe it's less of an emulation, given that the
> > CPU is at least running in the native 64-bit mode.
> /lib64 is taken from Solaris.
OK, so that's where the Solaris libs belong.
If I install a Solaris app on a Linux box,
it'll go there, and Linux libs go in /lib.
I'm glad we've cleared this up.
> > I could see /lib64 almost being sane if you ran
> > a 32-bit kernel that saved wide registers to
> > allow 64-bit apps to run without crashing, with
> > their virtual memory limited to the low 4 GB.
> > I wish people would just admit to having screwed
> > up and devise a plan to clean this very un-Linux
> > crud out of the world.
> This isn't going to change. It's supported on several architectures, and
> is pretty standard, and is supported down to the toolchain.
It's obviously not well supported. I've fought with
it on x86-64, with libtool thinking it ought to grab
some 32-bit libs during an XFS tools build.
"well supported" would mean that I don't have to
have arch-specific hacks to handle it.
> The location isn't the point for you anyway. The point for you is to
> build 32-bit and 64-bit libraries and bins and make them available. So
> stop your off-topic bitching and just do the right thing.
I've done the necessary thing, which is quite distinct
from the right thing. I've put two ugly hacks into my
formerly-beautiful Makefile. (x86-64 needed only one)
Build and install commands were portable across all
systems running libc5 or libc6 prior to this crap.
This beauty has been lost. Shame on you all.