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 /usr/X11R6. 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 Proud Canadian. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
