Expected Behavior

It should be possible to load plugins in the toplevel.

Actual Behavior

There are actually two independent problems.

Problem 1

First, the dune-site.plugins library is incomplete as it misses the Dune_site_data module.

Reference to undefined global `Dune_site__Dune_site_data'

Workaround/Solution

This module is generated at link time when an executable is linked, so to make it work, we can link our own toplevel, and we just need to add dune-site.plugins to the libraries stanza that will force dune to generate this file. Once, the toplevel is linked (I am just using let () = Utop_main () but one could run the vanilla toplevel using Topmain.main ().

While this problem has a workaround it would be nice to have the ability to generate self-contained libraries that are loadable in runtime. I didn't test it, but it might be that using the shared_object mode of an executable will build such a library. I will update the report if it will work.

Problem 2

Now to the main problem. When we try loading plugins from our toplevel, every plugin fails with,

(Invalid_argument
 "The dynlink.cma library cannot be used inside the OCaml toplevel")

Indeed, dynlink is not supposed to work inside the toplevel, which provides its own dynamic loading facilities. Therefore, the plugin system of dune has to check if we are in the interactive mode (in the toplevel) and use Topdirs.dir_load instead of Dynlink.loadfile.

Solution

I have a solution that I will PR in a second (the link should appear below). It has some things to discuss. Especially from the usability point of view. But at least it allows me to load all BAP plugins in a toplevel without any issues.