[lfs-support] GCC specs file contains reference to /lib/ld-linux.so on a 64 bits machine

Ken Moffat zarniwhoop at ntlworld.com
Fri Oct 4 17:02:57 PDT 2013


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



More information about the lfs-support mailing list