Mike A. Harris
mharris at mharris.ca
Mon Jan 16 20:25:38 UTC 2006
Neal Becker wrote:
> Sure. I grabbed the latest krename-3.0.10 tar, and after minor editing to
> krename.spec included in the tar (copyright->license) try build:
> + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
> --mandir=/usr/share/man --infodir=/usr/share/info
> checking for X... libraries /usr/lib, headers .
> Nope, that won't work!
> If I add --enable-libsuffix=64:
> checking for X... libraries /usr/lib64, headers .
> This seems to happen on several kde packages I tried. I believe it is
> because of relocation of X from /usr/X11R6/lib64 to /usr/X11R6. I think
> kde packages had been fixed to look in /usr/X11R6/lib64, but now they would
> all need to be fixed to look in /usr/lib64 for X libs?
X moved from /usr/X11R6 to /usr, not from /usr/X11R6/lib64 to
On multilib architectures, all native 64bit libraries are in "lib64"
directories standardfare, with the exception of Itanium. Likewise,
all 32bit libraries are in "lib". This is the way it has always been.
The only thing that has changed with regard to X, is the prefix they
are installed into, but that has nothing to do with wether they are
32bit or 64bit.
Your problem lay elsewhere.
Mike A. Harris * Open Source Advocate * http://mharris.ca
More information about the fedora-devel-list