[lfs-support] New directory layout and FHS 3.0

Frans de Boer frans at fransdb.nl
Wed Dec 21 01:22:09 PST 2016


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.
>
>   -- Bruce
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?).

--- Frans.


More information about the lfs-support mailing list