Re: Compatibility between Debian amd64 and other distributions
Hello,
On 06-Sep-23 02:50, Goswin von Brederlow wrote:
> FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non
> Debian distributions follow that line.
Gentoo uses basically the same setup as Debian, i.e. it installs 64-bit
libraries in /usr/lib and it has a symlink from /usr/lib64 to /usr/lib.
> Steve Langasek had concerns about side-effects:
> > That probably means that a change for this would not be accepted
> > into etch, since fiddling library paths may have unexpected
> > side-effects and glibc is already frozen.
>
> So far I have seen none.
The proposed glibc patch will break the installer. The installer does not
have the symlink from /usr/lib64 to /usr/lib. (This is not by accident.
It has been decided following some discussion.)
The proposed patch changes the 64-bit library access paths used by glibc,
i.e. (s)libdir, from (/usr)/lib to (/usr)/lib64. With this change, the
/usr/lib64 symlink would become a necessary requirement for things to work
properly. Currently, the distribution works even without the /usr/lib64
symlink.
> Now I guess the release-team has to make a decision how important the
> FHS and compatibility is to Debian.
The proposed patch may improve compatibility with Redhat or Novell
but it does not improve compliance with the FHS.
The relevant parts of the FHS 2.3 are:
A) "/lib : Essential shared libraries and kernel modules
Purpose: The /lib directory contains those shared library images
needed to boot the system and run the commands in the root filesystem,
ie. by binaries in /bin and /sbin.
B) "/lib<qual> : Alternate format essential shared libraries (optional)
Purpose: There may be one or more variants of the /lib directory on
systems which support more than one binary format requiring separate
libraries. [Footnote:] This is commonly used for 64-bit or 32-bit
support on systems which support multiple binary formats, but require
libraries of the same name. In this case, /lib32 and /lib64 might be
the library directories, and /lib a symlink to one of them."
C) "/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place
64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries
in /lib. The 64-bit architecture IA64 must place 64-bit libraries in
/lib.
Rationale: This is a refinement of the general rules for /lib<qual>
and /usr/lib<qual>. The architectures PPC64, s390x, sparc64 and
AMD64 support support [sic!] both 32-bit (for s390 more precise 31-bit)
and 64-bit programs. Using lib for 32-bit binaries allows existing
binaries from the 32-bit systems to work without any changes:
such binaries are expected to be numerous. IA-64 uses a different
scheme, reflecting the deprecation of 32-bit binaries (and hence
libraries) on that architecture."
Summarized, Debian and Gentoo comply with A) and B) but not with C)
while Redhat and Novell comply with B) and C) but not with A).
It could be argued that the special rule C) overrides the general rule A).
On the other hand, the "Rationale" of C) shows that C) was designed
specifically for i386/amd64 biarch distributions with a strong i386
32-bit part. But Debian amd64 is a full native 64-bit distribution.
The 32-bit part is purely optional and many people will not install
any 32-bit binaries at all on their amd64 machines.
The status quo for 64-bit and 32-bit libraries on Debian amd64
is as follows:
1) (/usr/)/lib64 is a symlink to (/usr)/lib
2) The dynamic linker name is /lib64/ld-linux-x86-64.so.2 (as per LSB).
3) 64-bit libraries are installed in /usr/lib and accessed via /usr/lib.
4) 32-bit libraries are installed in /emul/ia32-linux/(usr/)lib and
there are symlinks from (/usr)/lib32 to /emul/ia32-linux(/usr)/lib.
1), 2) and 3) are consistent with the FHS 2.3 as long as no 32-bit
libraries are installed on the system. Only 4) is a deviation from C)
with respect to the location of the 32-bit libraries.
The FHS 2.3 rule C) mandates that 32-bit libraries have to be stored in
(/usr)/lib on amd64. To implement this in Debian would be difficult
because almost every library package would have to be changed to install
the native library files in a separate /usr/lib64 directory instead
of the usual /usr/lib.
The other Debian ports have their native libraries installed in /usr/lib.
Many packages rely on this fact. Many things, especially during the build
process, will break if the native libraries are not in /usr/lib.
It would be a _lot_ of work to change the whole distribution to use
/usr/lib64 instead of /usr/lib as the location of the native libraries.
Regards
Andreas Jochens
Reply to: