Re: multiarch and interpreters/runtimes
Le 18/04/2013 16:41, Matthias Klose a écrit :
> So what is the status for some runtimes/interpreters (would like to see some
> follow-up/corrections from package maintainers)?
> [...]
> - Lua, Ocaml, Haskell, Guile, ... ?
First, let me explain a few notions that will be useful to grasp the
situation of OCaml wrt multiarch. There are actually two compilers.
One of them is the "bytecode" one and uses its own binary format for
compiled objects. For pure OCaml code, this bytecode is portable (pretty
much like Java). There is no shared library mechanism and all
executables are statically linked. There is a FFI mechanism that seems
to work like Perl, Python and Java (if there is something fundamentally
different between these three, please tell me as I've probably
misunderstood something). I expect the same issues here wrt multiarch,
but I don't understand them fully yet. Foreign code (from the language
point of view, not dpkg's one!) is usually called "bindings" in OCaml
community. The bytecode compiler (/usr/bin/ocamlc) and runtime
(/usr/bin/ocamlrun, written in C) are equally supported on all Debian
architectures.
The other compiler is the "native" one (/usr/bin/ocamlopt), which
compiles to asm and uses the regular toolchain (as, ld...). There is no
shared library mechanism for OCaml code (and the runtime is always
statically linked), but the resulting executables can still use shared
libraries because of bindings. The native compiler only exists on a
handful of architectures. I expect no problems here wrt multiarch (or,
let's say no more that with any C program).
Note that, though portable, bytecode is usually recompiled on all
architectures because of native code (we don't bother to put bytecode
and native code in different binary packages).
Additionally, there is what is called the "plugin" mechanism with both
compilers, which can be thought as an equivalent of dlopen (but not mere
FFI).
It turns out that most of the files needed for development (static
libraries, compiled headers, metadata files) and runtime (bindings for
bytecode, libraries in plugin form) are all installed in `ocamlc
-where`, which is currently /usr/lib/ocaml, but could be changed easily.
This is basically forced by the upstream toolchain (and our policy in
Debian).
However, there is no real standard for plugins, which can be in `ocamlc
-where` or not, depending of the application using them. But AFAIK,
there are very few packages that use the plugin mechanism with plugins
outside of `ocamlc -where`.
So my take would be to move `ocamlc -where` to
/usr/lib/$DEB_HOST_MULTIARCH/ocaml (it can be done during the next
transition). Most of library packages (runtime AND dev) ship files only
there (and in /usr/share). After that, I don't know exactly what needs
to be done.
Concerning cross-compilation... well, there is no out-of-the-box
upstream support for cross-compilation, but I guess it can be hacked
(see mingw-ocaml... but Romain Beauxis is more knowledgeable on this).
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of the
build process (i.e. ocaml doesn't build-depend on itself). So no need
for cross-compilation there. OCaml has very few build-dependencies
(there are Tcl/Tk/libX11, but they are optional) and should always be
buildable natively.
Concerning embedding the runtime in another application... well, that
doesn't seem to happen often. The only case I'm aware of is an Apache
module and I don't know exactly how multiarch would interact in that.
From what I've seen, when there is a need for OCaml scripting
capabilities, the main application is already written in OCaml, and the
regular toolchain is used to compile the script into a plugin and load
it on the fly.
Cheers,
--
Stéphane
Reply to: