Dynamic link

[Nicolas GEORGE <nicolas.george@ens.fr>]

I have written a small patch to the OCaml (2.99) run-time, that enables to
dynamically load C primitives, instead to have to link against a custom
run-time. It is far from perfect, but at this time, it works (under Unix
systems).

The main problem is that it's a bit hand made.

- the bytecode file has to be linked using the -use-prims undocumented
  option
- the run-time must be called with a -dfilename option, where filename is
  a primitive database (each line is the name of a .so file or of a symbol
  in the last .so file)
- instead of checking the constitency between the primitive list of the
  run-time and of the bytecode, it loads the needed symbols (here, I should
  have built a hash table instead of that stupid search)
- the libraries have to resolve themselves their external dependencies (I
  use ld -G -l*)
- there is a small memory waste (2kb) because the names of the builtins
  primitives are twice im memory

Of course, there are some points to solve. The linker should build himself
the list of needed primitives, but I was too affraid to touch the compiler.
I don't know how to make that work under windows (but I think it is
aproximativly the same) or mac, but it is not _necessary_.

One main advantage is to can use OCaml for small applications (such as
simple front-ends) that needs special libraries (GUI, Unix, Str...) without
the 1/2 megabyte of the custom run-time.

The patch is available at:
http://www.eleves.ens.fr:8080/home/george/informatique/ocaml-2.99-dl.patch

Here is an example of code:




J'ai écrit un petit patch pour le run-time OCaml (2.99), qui permet de
charder dynamiquement des primitives C, à la place d'avoir à lier contre un
run-time personnalisé. Il est loin d'être parfait, mais à l'heure actuelle,
il marche (sous des systèmes Unix).

Le principal problème est qu'il est un peu artisanal.

- le fichier de bytecode doit être lié en utilisant l'option
  non-docummentée -use-prims
- le run-time doit être appelé avec une option -dnomdefichier, où
  nomdefichier est une base de données de primitives (chaque ligne est le
  nom d'un fichier .so ou d'un symbole du dernier fichier .so)
- au lieu de vérifier la consistance entre les listes de primitives du
  run-time et du bytecode, il charge les symboles nécessaires (ici,
  j'aurais dû construire une table de hachage au lieu de cette recherche
  stupide)
- les bibliothèques doivent résoudre elles-mêmes leurs dépendances externes
  (J'utilise ld -G -l*)
- il y a un léger gaspillage de mémoire (2ko) parceque les noms des
  primitives internes sont deux fois en mémoire

Bien sûr, il y a des points à résoidre. L'éditeur de liens devrait
construire lui-même la liste des primitives nécessaires, mais j'avais trop
peur pour toucher au compilateur. Je ne sais pas comment faire marcher ça
sous windows (mais je crois que c'est approximativement la même chose) ou
sur mac, mais ce n'est pas _indispensable_.

Un principal avantage est de pouvoir utiliser OCaml pour de petites
applications (comme des front-ends simples) qui ont besoin de bibliothèques
spéciales (GUI, Unix, Str...) sans le 1/2 mégaoctet du run-time
personnalisé.

Le patch est disponible en :
http://www.eleves.ens.fr:8080/home/george/informatique/ocaml-2.99-dl.patch

Voici un exemple de code :



libtestpatch.c:
/*
gcc -I/usr/local/util/packages/ocaml-2.99/lib/ocaml \
`gtk-config --cflags` -O2 -c libtestpatch.c
ld -G -o libtestpatch.so libtestpatch.o `gtk-config --libs`
*/

#include <caml/mlvalues.h>
#include <caml/memory.h>
#include <gtk/gtk.h>

void ml_test(void)
{
  CAMLparam0();
  gtk_init(NULL,NULL);
  gtk_widget_show(gtk_window_new(GTK_WINDOW_TOPLEVEL));
  gtk_main();
  CAMLreturn(Val_unit);
}

testpatch.ml:
external test : unit -> unit = "ml_test"

let () = print_string "Bonjour";
  print_newline ();
  test ()

List of primitives to use with -use-prims:
ocamlrun -p > primlist.cmp
echo ml_test >> primlist.cmp

List of primitives to use with -d:
/some/where/libtestpatch.so
ml_test