Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynlink/packing issue in bytecode with 4.08 #8816

maroneze opened this issue Jul 19, 2019 · 1 comment


Copy link

commented Jul 19, 2019

With 4.08 (including the 4.08.1+rc1), we have an issue with the bytecode version of Frama-C, where the dynamic loading of modules (via Dynlink) no longer works as before, with error messages such as "no implementation available for ".

A quick glance through the changelog did not indicate a likely culprit. We had a typing issue related to -pack which has already been solved in our development version, but this bug might be unrelated, since we can now type, compile and run Frama-C in native version without issues.

For a more concrete description, here's an example of what happens when trying to run frama-c.byte after compiling it, in 4.08 (among several similar messages):

[kernel] User Error: cannot load plug-in 'Callgraph': cannot load module
  Details: no implementation available for Callgraph.Options

Callgraph.cmo is produced by packing several modules, including an options.cmo. This compiles, both in bytecode and in native version, and when running the native version of Frama-C (which loads the corresponding .cmxs file), everything works fine. However, when running the bytecode version (frama-c.byte), these errors appear. Both versions work fine up to 4.07. (I could not test with 4.09 since we depend on dune, but I assume no changes related to it.)

We can try to produce a minimal, self-contained version, but it could take some time. Do you have an idea of something else we could do to further debug this issue?


This comment has been minimized.

Copy link

commented Jul 19, 2019

The mistake is in #2176 which treats Symtable.required_globals as if all persistent identifiers returned by it will be toplevel modules, which is not true for a packed cmo file where it will also contain sub-modules.

The fix is just to ignore identifiers with "." in their name when creating the list of implementation_imports in the bytecode implementation of I'll make a PR this afternoon.

lpw25 added a commit to lpw25/ocaml that referenced this issue Jul 19, 2019

dra27 added a commit to lpw25/ocaml that referenced this issue Jul 20, 2019

@gasche gasche closed this in #8818 Jul 23, 2019

gasche added a commit that referenced this issue Jul 23, 2019

Merge pull request #8818 from lpw25/fix-dynlink-packs
Fix #8816 (Dynlink/packing issue in bytecode with 4.08)

gasche added a commit to gasche/ocaml that referenced this issue Jul 23, 2019

Merge pull request ocaml#8818 from lpw25/fix-dynlink-packs
Fix ocaml#8816 (Dynlink/packing issue in bytecode with 4.08)

(cherry picked from commit e14a611)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.