Weekly Edition
Return to the Distributions page
| |||||||||||||
Debian multiarch support
Multiarch is a concept that involves the ability to run binaries compiled
on one architecture on machines with a different architecture.
For example, an amd64 system Linux system would be able to run the
same binary programs that run on an i386 Linux system. This idea has been
talked about by a few Debian developers for at least a couple of years.
This week Matt Taggart posted an update on the Debian-devel mailing list, with a pointer to a wiki where information and status is being tracked, and a pointer to a report (PDF) entitled Multi-Arch Implementation Strategy, prepared for HP by Canonical Ltd. What follows is a summary of the report. The report looks at various ways to extend Debian (and derived systems) to provide multiarch support. Implementation strategies will be tested during the upcoming Ubuntu Eft development cycle and, hopefully, be deployed in the Debian etch release. The primary problem with multiarch support is in shared libraries normally located in the /usr/lib directory. These libraries are shared by many binary programs and they may also contain architecture specific information. For example, and an AMD64 library would specify such things as address space, calling conventions, word and data sizes, and other information that would not allow a program to load on i386 system. The currently favored solution is to move the libraries into arch-named subdirectories under /usr/lib. This would allow the binary package to link to the correct architecture specific library. Another problem is in the architecture dependent binaries in /usr/bin and /usr/sbin. An openssl binary complied for the i386 architecture might run quite well on an amd64 system, but that amd64 system can't have the native version of openssl installed at the same time unless the system administrator put the package in /opt or /usr/local. The proposed location for all architecture-independent binaries is under /usr/share. When creating shared libraries, developers should keep separate the architecture-dependent files from the architecture-independent files and avoid hard coding the paths to architecture-dependent files. This will avoid naming conflicts, save space, and allow the architecture-dependent files to moved or renamed as needed. Ideally a multiarch system should not need special packages and should not waste disk space unnecessarily. Package maintainers and system administrators should not need to know more or do more to make the system work. Configuration files should be easily shared by multiple systems. In the long term upstream developers will need to be retrained to write code that can be more easily shared. In the short term, chroots should be used when installing software from multiple architectures. Environment packages, multiple binary production and automated package rewriting could also help in the short term. An attempt to get OpenOffice.org 2 running on a multiarch system was used as a feasibility study. While it would be highly desirable to have a multiarch OOo, it was not designed that way and numerous problems were encountered in the process. Ultimately they recommend that multiarch support be built into the package manager. While rewriting massive amounts of existing code is not really feasible, new developers would do well to keep multiarch guidelines in mind when creating new packages and libraries. (Log in to post comments)
Debian multiarch support Posted May 18, 2006 6:36 UTC (Thu) by dmantione (guest, #4640) [Link] This should be no issue for discussion: According to the x86-64 ABI32-bit binaries go in /lib, 64-bit binaries go in /lib64: http://www.x86-64.org/documentation/abi-0.96.pdf The reason is simple: This is the only way you can install (RPM) packages designed for i386 systems on your x86-64 systems. You can simply forget what architecture the package has, it just works.
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.
Debian multiarch support 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.
Debian multiarch support Posted May 18, 2006 15:10 UTC (Thu) by elanthis (guest, #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).
Debian multiarch support 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 (formerlypure64) 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.
Debian multiarch support Posted May 19, 2006 19:19 UTC (Fri) by msw (subscriber, #3733) [Link] Red Hat did not invent lib64. It was in use in Irix well before it appeared in Linux (to my knowledge).
Debian multiarch support Posted May 18, 2006 8:07 UTC (Thu) by wookey (subscriber, #5501) [Link] Multiarch actually has wider use case than the obvious one of letting amd64 systems run both 64 and 32 bit binaries/libs. It also helps with cross-compilation issues, by having a standard place to install non-native libs (of multiple types) and a packagemanager that can cope with this. dpkg-cross currently provides this functiponality by re-writing paths in standard packages to make them cross-installable. Multiarch should make that aspect of dpkg-cross redundant.
I think it can also help with cross-building schemes which use emulation to run target binaries at build-time, but I need to think about it a bit more first.
So embedded/cross-building people should be keen to see multiarch happen, even if they don't care at all about amd64 64/32 mixed installations.
/usr/share Posted May 18, 2006 21:58 UTC (Thu) by rfunk (subscriber, #4054) [Link] "The proposed location for all architecture-independent binaries isunder /usr/share." I hope that refers to executables that truly run on *any* supported architecture, generally only scripts. /usr/share would be a very bad place for x86/x86-64 binaries that won't run on PPC.
/usr/share Posted May 19, 2006 15:58 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] It's probably better to say "architecture independent files." When I hear the word "binary" referring to a file I usually think "executable." I think what they mean here are all the supporting files for an application, which may include image files, documentation files, and other fairly static things.
/usr/share Posted May 19, 2006 16:07 UTC (Fri) by rfunk (subscriber, #4054) [Link] Yes, that's pretty much what /usr/share is intended for, but the factthat it was mentioned seems to imply a change of some sort.
/usr/share Posted May 19, 2006 16:24 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Well, it appears a bunch of otherwise arch-neutral stuff ends up in places like /var/lib currently. On my Ubuntu box, for instance, there's a bunch of Firefox files in /var/lib/mozilla-firefox, and they appear at first blush to be arch-neutral--they're all .rdf and .txt files pretty much. All the doc files, though, are in /usr/share/doc/mozilla-firefox/.
/usr/share Posted May 19, 2006 16:44 UTC (Fri) by rfunk (subscriber, #4054) [Link] Yes, /var is for files that change a lot during runtime. /usr onlychanges when you upgrade the OS (or pieces of it). This is all explained in the Filesystem Hierarchy Standard. http://www.pathname.com/fhs/
i386 running amd64 binaries? Posted May 19, 2006 0:46 UTC (Fri) by ncm (subscriber, #165) [Link] I'm finding it hard to believe that multiarch is all it takes to let you run amd64 binaries on an i386 host, as the first paragraph suggests. Has an amd64 instruction-level emulator been added since last I checked, or should it say, instead, that it lets you run i386-compiled binaries on your amd64 system?
Re: i386 running amd64 binaries? Posted May 19, 2006 11:48 UTC (Fri) by interalia (subscriber, #26615) [Link] multiarch is mostly just a structural thing. Obviously, rearranging files and dynamic linkers on its own won't allow someone to run binaries for amd64 on i386, as you implied. But it lets you parallel-install them cleanly, which is great. multiarch not meant for simply having amd64/i386 co-exist, the idea is to have a consistent structure even if you want three or more architectures, something that the "/lib and /lib64" solution doesn't provide. The proponents contrast multiarch with the existing approach, which they call bi-arch.
As posited in previous comments, you might have a third /usr/lib/xx-yy-zz area for cross-compiling to ppc. Then you might run the compiled ppc programs using a native amd64 binary which is a ppc emulator. Perhaps even WINE could somehow become an arch for this purpose. If you read the threads on multiarch, people have come up with all sorts of ideas that can be done when you aren't limited to whether something is 32-bit or 64-bit.
Debian multiarch support Posted May 30, 2006 7:31 UTC (Tue) by dmaas (guest, #38073) [Link] I am glad to see more attention brought to this issue.
I maintain a network of 32- and 64-bit x86 systems for my company. For various reasons it is highly desirable for all systems to run the same disk image (except the kernel, of course). We want to run a handful of computation-intensive software in 64-bit mode on the systems that support it, but everything else can be 32-bit.
I started with a plain 32-bit Debian system and manually added in a few pieces from 64-bit Fedora Core (mainly /lib64 and /usr/lib64) - just enough of the basic libraries to run the computation-intensive 64-bit packages.
It has worked out surprisingly well. I did notice one problem the article points out, which is conflicting binaries in /bin and /usr/bin. I had to install 64-bit versions of certain low-level tools like modprobe, strace, and ps to support the 64-bit systems. I did this by renaming the 32-bit versions to modprobe32, strace32, etc, appending similar suffixes to the 64-bit versions, and writing wrapper scripts which picked the right version to run on a particular machine. Thankfully there were only a handful of these cases.
The other nasty issue was glibc headers. The contents of /usr/include/asm and /usr/include/bits are platform-specific. I followed RedHat's model of installing both x86 and x86_64 headers with different names and picking the right one using small "stub" headers. I wish glibc would install its headers in a more platform-neutral manner.
(incidentally, some of you might want to read up on Plan 9, which solved this problem years ago :)
Debian multiarch support Posted Dec 18, 2006 10:54 UTC (Mon) by k8to (subscriber, #15413) [Link] Wow. It's now six months after this proposal, and I see no movement.
Also, it's been over two years since this arch came on the market and the obvious need for multi-arch arose. Usually I'm pretty content with the slow pace of progress in Debian, in that it brings a lack of pain, but this particular issue is a point of discontent.
In order to get a bi-arch distribution with extremely broad package support, what, if any, are my options?
|
|||||||||||||