On November 10, 2018 7:13:53 AM CST, John Frankish via lfs-dev 
<lfs-dev@lists.linuxfromscratch.org> 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?
>
>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.
>
>-- 
>http://lists.linuxfromscratch.org/listinfo/lfs-dev
>FAQ: http://www.linuxfromscratch.org/faq/
>Unsubscribe: See the above information page

It goes deeper than this. *You* certainly can do either, we've done it before, 
but it breaks ABI. LFS cannot do this as a project. This is for multiple 
reasons. The first purpose of this was to support both 32bit and 64bit builds 
with minimal abuse of uname in the instructions. The second was simply having 
/lib as the primary lib directory, with any lib<qual> as secondary. This was in 
a bit of contention prior to the latest revision of the FHS, hence the 
different methods used by Debian and Red Hat.

HTH

--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

Reply via email to