On 08/21/2017 09:12 PM, Dutch Ingraham wrote: > For example, Fedora (and Gentoo, > etc. ) > also installs glibc for both 32- and 64-bit on the same machine, but > they have not > relocated these header files. So are you saying this was just Debian's > method > of solving the multi-arch issue, and other distributions solved in some > other way?
Other distributions' support for multiple architectures is limited to 32bit and 64bit of the same fundamental CPU - for example 32bit and 64bit Intel/AMD CPUs. In these cases the header files that are installed have traditionally been the same (just with #ifdef in them for things that differ). What you can't do on those distributions is install packages from foreign architectures on your local system; for example you can't install a library for ARM on a system with Intel/AMD CPUs on those systems. Debian and Ubuntu decided to go a more thorough route here: instead of just supporting the parallel installation of 32bit and 64bit packages they decided to fully support the installation of packages from arbitrary architectures. This means that instead of having /usr/lib32 and /usr/lib64, you have /usr/lib/ARCH (where ARCH is the triplet that specifies the architecture, for example x86_64-linux-gnu or arm-linux-gnueabihf) and /usr/include/ARCH. Libraries themselves should not be installed in /usr/lib directly anymore (and most libraries have already moved to /usr/lib/ARCH, but some packages haven't yet), while /usr/include (without ARCH) does still have a purpose: for those headers where the architecture doesn't play a role at all. Architecture-dependent headers should go into /usr/include/ARCH instead though. The compiler and linker are configured in such a way that they'll look in _both_ directories by default (with a preference for the ARCH directory) when searching for header files and libraries. Now it might seem strange to do this, as you can't natively run an ARM application on an Intel/AMD CPU (you'd need an emulator for that, though there are such things for binaries alone, take a look at qemu-user for that), but there are other benefits to this scheme: - You can use this scheme to cross-compile to other architectures. Want to create an arm64 Debian package? Install the build dependent libraries in their arm64 variants on your system and you can do so (if the package supports cross-compiling, which not all do). - Since there's no arbitrary restriction of 32bit and 64bit that may be installed in parallel, there are cases when there are two different 32bit architectures you may want to install in parallel. For example, there are two 32bit ARM variants supported by Debian at the moment: armel and armhf. Both use the ARM EABI binary interface, but armhf assumes that ARMv7 floating point instructions are present in the CPU (along with the corresponding registers) while armel uses software emulation for floating point instructions (to support ARM CPUs that don't have them). Now say you have an ARM application (from a 3rd- party repository for example) that was compiled for armel, but your system is armhf. In Debian you can just install the libraries required for that program in their armel variant onto your otherwise armhf system and you can run that program. Whereas other distributions would put the libraries for both variants in /lib32 (or just /lib) in those cases, so you could not install the same libraries for both architectures - which also includes the system C library. - Code compiled for alternative C libraries (e.g. musl instead of glibc) can't be linked against code compiled for the standard C library. In Debian you have a trivial way of installing code that was compiled for both: alternative C libraries use a different architecture specifier, in the case of musl for example x86_64-linux-musl (vs. x86_64-linux-gnu) and you can also install libraries compiled for both variants in parallel. The only disadvantage in my eyes seems to be that Debian and its derivatives (Ubuntu, etc.) are the only ones that do this, and all the other distributions seem to favor the /lib32 vs /lib64 variant to do this. Regards, Christian
