Bonjour à tous !
Je viens d'observer un comportement étrange avec Scanf et Dynlink, qui m'ennuie beaucoup. J'ignore cependant s'il s'agit d'une erreur de ma part ou d'un bug. J'ai d'ores et déjà soumis un rapport de bug sur le bug tracker d'OCaml ; mais en raison des délais, je me permets aussi de soulever la question ici.
L'idée est très simple. Voici un fichier main.ml qui contient un prog tout simple (et parfaitement sans intérêt) destiné à charger dynamiquement des plugins ou fichiers partagés (fichiers .cmxs) :
Code ocaml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 (* ocamlopt dynlink.cmxa -o main main.ml *) open Dynlink let load x = try loadfile x with Error e -> prerr_endline (error_message e) let _ = Arg.parse [] load "Usage: main <plugin>"
Voici maintenant le plugin que l'on souhaite charger (plugin.ml) :
Code ocaml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 (* ocamlopt -share -o plugin.cmxs plugin.ml *) let _ = let str = read_line () in Scanf.sscanf str "%d" (fun _ -> print_endline "Done")
Après compilation avec OCaml 3.11.0, lorsque je lance ./main plugin.cmxs dans un terminal, j'obtiens toujours la même erreur :
error loading shared library: plugin.cmxs: undefined symbol: camlScanf__from_string_148
Avec un nom pareil, j'ai décidé d'enlever tout appel à Scanf dans le code du plugin... et le problème disparaît.
Observez-vous aussi ce comportement ? Merci d'avance.
Cordialement,
Cacophrène
PS : Ce n'est pas la première fois que Scanf me donne des résultats pour le moins étranges. La toute première fois, c'était avec la fonction Scanf.format_from_string. Et je doute que le problème soit corrigé... mais c'est une autre histoire qui ne nous intéresse pas ici.
Partager