Debian multiarch support
Posted May 18, 2006 15:10 UTC (Thu) by
elanthis (subscriber, #6227)
In reply to:
Debian multiarch support by dmantione
Parent article:
Debian multiarch support
The future LSB specs are likely going to change on that front. The /lib64 stuff is likely to become a symlink.
Simply put, there are many cases where you want more than just x86 and x86-64 on a system. Maybe you want PPC and PPC64. Or maybe you even want x86 and PPC. Another common one is x86 and IA64. In that scenario, the 32-bit libs don't go in /lib, they go in /emu/x86 (or something similar to that). Even though that's "standard" according to various ABI specs, it then makes it impossible to have a single x86 package that installs to both a native x86 machine, and x86-64 machine, and an IA32 machine. And a system that runs PPC natively but has x86 emulation features (for running those pesky x86 proprietary apps) is going to need yet another path.
Then, we don't just have issues of hardware architecture, but also the kernel and OS interface. Many OS's can run Linux binaries, for example, but you need to put them in chroots and such in most cases so that you can separate the native version of libraries with the Linux version of the libraries. Multiarch can solve this problem, too.
By putting all libraries in a standardized path like /lib/linux-gnu-x86, /lib/solaris-sun-sparc, /lib/linux-gnu-ia32, and so on, it becomes possible to have a single installed system that can run binaries from multiple OS's and multiple architectures, even in cases where the host CPU doesn't have some built-in compatibility system. (Think PPC binaries running on x86/x86-64 CPUs with Rosetta under OS X.)
So, while I'm very sure that x86-64 users are the big pushers for multiarch (I know that's what _I_ want it), there _are_ many other use cases for it that can't be solved cleanly without either it or massive chroots (and the headaches those bring, like trying to sync configuration).
(
Log in to post comments)