On Sat, Feb 6, 2010 at 8:39 PM, Csaba Halász <csaba.halasz@...> wrote:
> On Sat, Feb 6, 2010 at 5:17 PM, Tim Moore <timoore33@...> wrote:
> > On Sat, Feb 6, 2010 at 4:18 PM, John Denker <jsd@...> wrote:
> >> On 02/06/2010 07:54 AM, Csaba Halász wrote:
> >> > On 64 bit systems /lib64 should really be a symlink to /lib (similarly
> >> > for /usr/lib64) as that is the native architecture.
> >> > I say copy the stuff from lib64 to lib and create the symlink.
> >> That is one way of doing it.
> > No, see my previous message.
> On native 64 bits systems there is no point in having a separate /lib
> and /lib64 - I certainly don't see any. Debian does provide the
> symlinks as I said.
> Do you run any 32 bit applications on your 64 bit system, like Google
Earth? They expect 32 bit libraries in /lib. It's possible that the Debian
runtime loader plays games to look in some other place for 32 bit libs or
appends a suffix to them; I don't know. On Fedora, the 32 bit libs have the
same names as the 64 bit libs and are installed in /lib, /usr/lib, etc.
> > The autoconf scripts do need to be brought into the modern 64 bit world,
> > ideally in a way that still permits building 32 bit binaries on 64 bit
> > systems. However, "it" does seem to "work out of the box" for most
> > which is why the bug remains.
> Yes, I guess most people just build for their native system. If not, I
> expect they would install into separate prefixes anyway.
> A fix would be nice, but I suppose most other bugs on your JD's list
> are more important.
> I try to ignore the autoconf stuff, but I'll see what I can do. Cmake,