[lfs-support] New directory layout and FHS 3.0

Bruce Dubbs bruce.dubbs at gmail.com
Wed Dec 21 08:48:51 PST 2016

Frans de Boer wrote:
> On 20-12-16 23:02, Bruce Dubbs wrote:
>> Frans de Boer wrote:
>>> On 20-12-16 21:56, Bruce Dubbs wrote:
>>>> Frans de Boer wrote:
>>>>> Hi all,
>>>>> I just noticed that there are changes in the development version of
>>>>> LFS,
>>>>> related to x86_64 architecture. But i do miss the rationale and/or more
>>>>> explanation. The latter is important because I see several changes
>>>>> which
>>>>> make sense, but misses other related changes in various other packages.
>>>>> Also having now /lib64 as a directory instead of a link puzzles me. The
>>>>> more because /lib is still a directory and not a link to /lib64 as per
>>>>> FHS
>>>>> 3.0.
>>>> Where does FHS 3.0 say a symlink is required?
>>>> What additional explanation would you suggest and where should it be?
>>>>> Looking at the FHS 3.0 documentation does not help either since the new
>>>>> LFS directory structure seems to be a non-consistent mix of various
>>>>> possibilities. See above and next example: /usr/lib with redundant link
>>>>> /usr/lib64.
>>>> 4.8. /usr/lib<qual> : Alternate format libraries (optional)
>>>> does not seem to require /usr/lib64.
>>> Footnote 13 makes an implicit reference to it. But I admit, it's not a
>>> very strong point.
>>> However, it seems not consistent to have /usr/lib and in the root /lib64.
>>> Use of qualifiers is - as I read it - only meant to be use by
>>> multi-library systems, which LFS explicitly states currently that it
>>> is not.
>> That's right, but there are apps that hard code some assumptions so
>> /lib64 with its two symlinks is a workaround.  If we could reliably
>> remove it, we would.
>>> Also, I never implied that having /lib64 does require /usr/lib64 - simply
>>> because there is no hard relation between them or their content. It's
>>> just
>>> what I stated above, inconsistent use of qualifiers.
>> OK, but we do't need /usr/lib64 and not having it makes things easier
>> for us (for the most part).
>>> By the way: Having /lib64 and /usr/lib64 as links to their respective lib
>>> directory make sense only when using third party (binary) packages.
>> Agree for the most part.  Some packages require a patch to avoid the
>> need and finding where the changes are needed is often difficult.
>>> Finally on the matter of explanation: sure, I can write one and find a
>>> place to put it up. But we first need to get into the "inconsistency"
>>> issue to be able to make a coherent and justifiable explanation.
>> As I said, it is a workaround.  I'd prefer that it was not needed.
>> Even with our changes, look at the adjsuting page in Chapter 6:
>> echo 'int main(){}' > dummy.c
>> cc dummy.c -v -Wl,--verbose &> dummy.log
>> readelf -l a.out | grep ': /lib'
>>       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
>> I'm not sure if that /lib64 is in glibc or binutils (probably glibc),
>> but it would need to be fixed to remove /lib64.

> I will send the needed patches I made in the past for other packages. Thus
> eliminating the need in LFS for qualified library directories.
> I have, however, not used those for some time, which needs therefor some
> (re)testing. Due to the coming holidays, I guess I can send them in
> sometime next week (to the bug-list?).

We can review these packages whenever you send them, but we will want to 
be careful as we get ready for the next (8.0) release.

   -- Bruce

More information about the lfs-support mailing list