On 28-12-16 21:29, Tollef Fog Heen wrote:
]] Frans de Boer
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.
If this is changed, it should be changed to just be multiarch compatible
specifiers. The idea that a given machine can only support as single
ABI with a given number of address bits is not true. (i386, amd64, x32;
MIPS o32, n32 and n64 come to mind.)
Of course I know that those systems can support multiple bit sizes, but
the FHS 3.0 leaves this all open. Nowhere it is stated that machines
with only a single bit size should have only /lib, the may have (or not)
a qualifier tagged to it. If I chose to have only 64-bit libraries on my
amd64, I am free to only use library directories without qualifier.
That said, I can appreciate also the idea that on hardware capable of
handling multiple architectures - read size of data paths - you always
use qualifiers, regardless if only one or multiple library directories
are used. So my previous second proposal is then augmented into:
[/usr[/local]]/lib<qualifier> for each different set of libraries
For compatibility one should also add
[/usr/[/local]]/lib -> [/usr[/local]]/lib<qualifier>
Where .../lib links to the library directory supporting the native bit
size.
This implies that on 32-bit intel like systems, you always have a
[...]/lib32 directory, an optional [...]/lib16 and [...]/lib is a link
to [...]/lib32.
On 64-bit Intel like systems you have [...]/lib64, an optional
[...]/lib<32|16> and [...]/lib is a link to [...]/lib64.
The above schema is already in widespread use on 64-bit machines, with
the exception of the legacy use of [...]/lib for 32-bit library directories.
Also, modification of sources for glibc, gcc, libcap, perl etc, are not
needed anymore. Due to the fact that some of these packages are core
packages and it would require a lot of effort for the maintainers to
change their current hard coded assumptions into more flexible code.
Alas, I can't say anything about other than Intel like systems. But I
hope that - in my view - the current ambiguous specification in FHS 3.0
is soon a thing of the past.
--- Frans.
_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
