On November 10, 2018 9:00:32 AM CST, Xi Ruoyao via lfs-dev <lfs-dev@lists.linuxfromscratch.org> wrote: >On 2018-11-10 13:13 +0000, John Frankish via lfs-dev wrote: >> > > Ref: >> > > >> > > Linux From Scratch - Version SVN-20181106 Chapter 6. Installing >> > > Basic >> > > System Software 6.9. Glibc-2.28 >> > > >> > > The instructions mention: >> > > >> > > libc_cv_slibdir=/lib >> > > This variable sets the correct library for all systems. We do >> > > not want lib64 to be used. >> > > >> > > ..but after installation I needed the following sed for this to >> > > be >> > > true >> > > >> > > sed -i 's@lib64/ld-linux-x86-64.so.2@lib/ld-linux-x86-64.so.2@' >> > > /usr/bin/ldd >> > > >> > > >> > We still have a /lib64 directory, and two links: >> > ---------- >> > ld-linux-x86-64.so.2 -> ../lib/ld-linux-x86-64.so.2 >> > ld-lsb-x86-64.so.3 -> ../lib/ld-linux-x86-64.so.2 >> > ---------- >> > Those are mandated by LSB. Also, when running the sanity check at >> > the end >> > of "6.10-ajusting the toolchain", you'll see "/lib64/ld-linux-x86- >> > 64.so.2" is >> > encoded in elf executables. >> > >> > So ldd should run without the proposed sed. Note that it does no >> > harm. >> > >> > Now, setting libc_cv_slibdir allows the build machinery of other >> > packages >> > to use /lib for installing libraries (well, at least when they use >> > autoconf. >> > When installing cmake, a few files need a sed for preventing >> > installation in /lib64) >> > >> If LSB mandates that those links are present, does it allow for the >> actual files to be in /lib and the symlinks to be in /lib64? > >I'm not familiar with LSB but I think this is allowed.
https://wiki.linuxfoundation.org/lsb/start > >> If this is the case, then the loader can be in /lib (with a couple of >> small adjustments to the gcc build) and anybody who does not have a >> need to be LSB compliant can just delete /lib64, /usr/lib64 and >> things will still work - this is in fact what I have done. It's good to learn. >That's not just a LSB incompliance. The path to dynamic linker is hard >coded in ELF header. An unmodified GCC generate executables with the >dynamic linker "/lib64/ld-linux-x86-64.so.2". So your system will ONLY >run dynamic linked programs produced by your (modified) GCC. If you >want to use ANY binaries from other system you have to hack these >binaries (it's absolutely possible but I didn't tried), or create the >correct symlink. >I think maybe we should explain these issues in the book (I've >explained them for Chinese audiences in my LFS Chinese translation). That would be good. I had thought some of this is covered, but it should probably be expanded in whatever way we can explain. Also of note, should be the FHS. http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
