On 28-12-16 15:45, Frans de Boer wrote:
Dear Reader,
Working with LFS (Linux From Scratch) I have been annoyed for years by
the inconsistency allowed by FHS descriptions. I know that FHS is just a
guide to how a file system under Linux might be structured. The thing
bothered me the most was the degree of freedom and thus different
interpretations around the issue of library qualifiers. And, I am sure,
that will only get worse when we enter the realm of > 64-bit - like
128-bit - machines.
As I understand the FHS specifications, it is basically divided by one
issue: single- and multi-library systems. In other words: a single
library system has libraries only supporting the native bit size of the
host, whereas multi-library systems support also a smaller bit size like
32-bit and/or 16-bit if supported by the host.
Currently the allowed forms for single-library systems is
[/usr[/local]]/lib[qualifier], where qualifier is numeric 64, 48, 32 or
16, depending on the host native data width.
However, a single 64-bit system can - for instance - have the following
appearances for library directories: /lib64, /usr/lib and
/usr/local/lib64. But /usr/lib must have only 64-bit libraries too.
I noticed that some core packages (glibc, gcc, libcap, maybe more?) have
hard coded some of their library names for 64-bit systems with the
qualifier '64'. If one would like to have a system with only unqualified
host system libraries and the system is 64-bit, you have to patch all
those hard coded libraries.
For consistency and readability I propose only to prescribe the
following structures:
Non-multilib systems have no qualifier in any library directory name.
In case of compatibility with third party binaries, links with
qualifiers might solve that issue.
Example:
[/usr[/local]]/lib
are directory names on systems with only native host supported bit
size.
[/usr[/local]]/lib<qualifier> -> [/usr[/local]]/lib
are links to directory names. Only used for backward compatibility.
Multilib systems always have an qualifier in every library directory
name. Links without qualifier may be deployed to link to machine native
library directory names to support third party binaries who only support
libraries without qualifiers.
Example:
[/usr[/local]]/lib<qualifier>
are qualified directory names.
[/usr[/local]]/lib -> [/usr[/local]]/lib<qualifier>
are links to qualified directory names. Only used for (rare)
backward compatibility.
I am eager to read the responses, as I am most likely not the only
person seeking consistency in the use of data width qualifiers under Linux.
--- Frans.
After some time experimenting with the second proposal as starting
point, I found that it is much easier to convert hardcoded '[...]/lib64'
directives into '[...]/lib' directives as used by the LFS project then
the other way around. There are many more packages that use hardcoded
'[...]/lib' directives than I first expected. Patching all these - and
not missing one - is a task I see no end to it.
Also, the /lib directory is expected to exist to support kernel modules,
firmware and libraries used by code in the /bin and /sbin directories.
So the second proposal can still be used with the added requirement that
[/usr[/local]]/lib is now a mandatory link to the directory containing
the native machine libraries.
64-bit machines:
There is one issue still remaining: On a 64-bit machine capable of
executing 32-bit software, the directory containing 32-bit libraries is
now named as /usr[/local]/lib32. There is - in this case - no /lib32
directory since executables in /bin and /sbin are here always 64-bit.
This also implies that sources need to be modified to use the directive
[...]/lib32 instead of [...]/lib. It might be just as daunting a task as
for the lib64 directive.
As always, curious to reactions,
--- Frans.
_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
