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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518586c6.3070...@debian.org
