On Fri, Oct 04, 2013 at 11:15:30PM +0200, Afshin wrote: > Hi LFS Team > > I've read in the LFS book v7.4 at the section “6.10. Adjusting the > Toolchain” that is a good idea to visually inspect the GCC specs file > and that's what I did. I've noticed that there are 2 references > to /lib/ld-linux.so even if I'm using a 64 bits machine. So I replaced > them by /lib64/ld-linux-x86-64.so.2. Am I wrong or there is really a > mistake somewhere or maybe I made something wrong during the > construction of the temporary system? > /lib64/ld-linux-x86-64.so.2 is correct.
ISTR that the book has a note that the filename may vary, but I'm not going to look up the details - I've already misled one person this week :) > Generally do you have any feedback on the building of LFS on a 64 bits > machine? Before upgrading to the 7.4 I was using LFS 6.4 on a 32 bits > machine and had no such a problem. > I've been using 64-bit on LFS since before it was officially supported. In the early days, a few BLFS packages such as jpegsrc.v6b (sic) got confused and required their config files (e.g. config.guess) to be updated. Other occasional packages such as popt insisted on using /usr/lib64 instead of /usr/lib. Everything was solveable. The current LFS method of symlinking /lib64 to /lib isn't as pure or clean, but it works ok. > I read somewhere that using ldconfig is not recommended but I was > obliged to use it to go ahead as I was stuck for 2 days on the > compilation of the package file (problem to find the shared library > libz). > What do you mean by "the package file" ? Anyway, that sounds as if you made a mistake in installing libz : libz.so.1.2.8 should end up in /lib, with a symlink from /lib/libz.so.1 and another from /usr/lib/libz.so. This is a difference between 32-bit i686 and 64-bit : the static libz.a cannot be used in a shared 64-bit library, so the link fails if a shared libz isn't found. In 32-bit the link with libz.a will succeed, which might not be what you want. > I use Debian 7 (wheezy) installed in a Vmware fusion VM which is in turn > installed on an Apple iMac. Maybe glibc/gcc are too recent on my > machine to build the temporary system... > > Best Regards > Afshin > LOL. A debian release "too recent". After picking myself up from the floor, I suggest that building in a vm, and indeed using that hardware [ broken UEFI implementations have been noted on the kernel list, and each new version seems to bring problems with HID devices not being recognized by the kernel, until someone adds the fix ] are more likely to cause problems. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
