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.