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
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
to post comments)