multiarch and interpreters/runtimes
There are maybe not many use cases where you do want to install an interpreter
like python or perl for a foreign architecture, but there are some use case
where such a setup makes sense. For now I see this limited for architecture
pairs like amd64/i386, armel/armhf, ia64/i386, i.e. for architectures where the
"foreign" interpreter can be run (without qemu). Use cases are
- running the OpenJDK hotspot JIT for i386 on ia64, an implementation
which is much faster than the OpenJDK Zero interpreter on ia64.
This can be done today in wheezy. The OpenJDK packages do use
different prefixes and are co-installable. While the packages come
with binaries, these are all installed using alternatives, so the
packages can even be installed for more than architecture (no, I don't
like this alternatives schema much).
- running the IcedTea web plugin for i386 on amd64, because the
downloaded binary code is only available for i386. This is
currently possible in wheezy.
- running a gdb:amd64 on i386 to debug 64bit binaries. This is the
reason for our current gdb64 package on i386, but it is missing the
support for the python based pretty printer.
Installing gdb:amd64 on i386 in wheezy will remove the whole i386
python stack and then install the amd64 python stack. For this use
case the needed amd64 python stuff should just be installed without
removing the i386 packages.
- install vim for a foreign architecture. Ok, not really a good use case,
but it comes with an insane amount of embedded interpreters. It
should be installable without removing the "native" interpreter
packages, and the embedded interpreters should still be usable.
- Third party modules for interpreters should be cross-buildable.
Many build systems for interpreter languages are written in the
interpreter language itself. So you do require the interpreter
for the build, and the development files for the host.
When trying to build a base system, you meet build dependencies
on interpreters very early. You can either work around these
by staged builds, or provide an interpreter which supports cross
builds for third party packages. However most interpreters require
some work to cross-build, and you have to figure out how to cross
build the extensions.
So the gdb/vim use cases would require co-installation of the runtime files for
more than one architecture (including in most cases the shared library, some
standard libraries, or subset of these), and keeping the interpreter for the
default architecture.
The cross build case would require in addition co-installed development
packages, provided that these can be used for a cross-build.
So what is the status for some runtimes/interpreters (would like to see some
follow-up/corrections from package maintainers)?
- OpenJDK: runtime and development files are co-installable, the
package itself is not cross-buildable, and afaik nobody did try
to cross build any bindings.
- Perl: Afaik, Neil did prepare the interpreter to cross-build, and
to co-install the runtime and development files. What about
cross-building third party modules?
- Python: co-installable runtime and development files, cross-buildability
upstreamed for 2.7.4 and 3.3.1. There is a way to cross-build third
party modules using distutils/setuptools. Packages are available in
experimental, but because I didn't backport this to 2.6 and 3.2, not
much useful. Install an Ubuntu raring (13.04) chroot to experiment
with these. Details at http://wiki.debian.org/Python/MultiArch
- Ruby: Afaik, not yet started on multiarch.
- Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
are available in Debian bug reports.
Currently the shared libraries are split out into separate packages,
and are co-installable. Not yet tested if this enough to run an
embedded interpreter.
- Lua, Ocaml, Haskell, Guile, ... ?
Matthias
Reply to: