Debian multiarch support

Posted May 18, 2006 7:42 UTC (Thu) by kleptog (subscriber, #1183) [Link]

But where do the PPC64 libraries go?

It's all nice and good to have a solution for x86, but there are other architechtures that can support multiple ABI formats simultaneously, it would be nice to do it in a way that works for everyone.

Fortunatly, the dynamic linker is smart and solves 99% of the problem for us. We just need to make sure that packages don't try to install over the top of eachother.

Posted May 18, 2006 14:14 UTC (Thu) by msw (subscriber, #3733) [Link]

I helped implement the multiarch support in RPM, and it's not just that simple. Often you need to install both 32-bit and 64-bit packages at the same time. Sometimes bits of those packges overlap. This (sort of) works in RPM because two packages are allowed to own the same file if the contents are identical. This lead to a ton of work to make the packages in Red Hat produce exactly the same contents (for the non-architecture-specific files) on both 32-bit and 64-bit systems. Sounds like fun? I assure you it wasn't.

We took that experience and designed a new package management system from the ground up. One of the primary design goals was elegant multi-arch and multi-lib support. The result is Conary, which does a pretty amazing job. We've easily installed 32-bit OpenOffice.org or Firefox on a 64-bit system - out of the box.

Posted May 18, 2006 15:10 UTC (Thu) by elanthis (subscriber, #6227) [Link]

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).

Posted May 19, 2006 3:58 UTC (Fri) by jwb (guest, #15467) [Link]

This is the sort of parochial redhatism that led to the creation of the Debian amd64 (formerly
pure64) architecture. /lib64 is deeply broken for many reasons, not the least of which is the fact
that 64 is the native word length on some platforms and many people don't want to have 32-bit
binaries or libraries on their systems at all.