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.
Reply to: