On 2/29/12 11:33 PM, Qrux wrote: > Irony aside, I think it's fine to ask people to clarify, to prevent confusion > and save the time spent down rabbit holes.
Absolutely, that's what learning and sharing knowledge is all about. It sounded to me as if you were expressing frustration with Andy and with the style of communication here. If that wasn't the case, then my mistake. Just to be clear - the BIND code itself shouldn't care about lib or lib64. Its need for the symlink in BLFS has to do with where existing library dependencies live and where the compiler and linker has been told to look. It is possible that BIND's build system may also default to a lib64 location on x86_64 hosts, but that's rare for autoconf builds systems. In any case, that kind of thing is easily overwritten and the code itself shouldn't care. So the main reason for having lib64 as a symlink is for compatibility with pre-compiled binaries, drivers, etc. The SysV ABI was brought up, but it already seems to allow differences for Linux (and, it should be noted this is GNU/Linux - other libc implementations, even though valid with different linkers aren't even acknowledged). So without diving into the deeper discussion of multilib and assuming LFS stays pure64, it seems to boil down to two possibilities: 1. It's a symlink. It's trivial to add if it's needed. 2. It's a symlink. It's trivial to leave in the book. Part of why I personally prefer removing it has to do with the knowledge gained by doing so. If a package tries to install something to /lib64 - you know right away. Having the symlink(s) masks that. Of course, using DESTDIR or equivalent shows that up as well. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
