Comment author: administrator

when I dynlink something like

let a =
  let module M = MLast in M.loc_of_expr

I get a dynlink error "undefined global MLast. The equivalent

let a = MLast.loc_of_expr

load fine.

Generally speaking, when a program dynlinks a module A that references
a module B (B = MLast in your example), you must ensure that an
implementation of B is available, e.g. by linking B.cmo statically with
the program. Otherwise, you'll get "undefined global B" errors.

This is not the case in your program because dynlink_main was not
linked with an implementation of MLast. So, the error with the first
module above is normal.

Now, why is it that the second module causes no errors? Well,
MLast.loc_of_expr is a primitive ("external" declaration in MLast.mli)
and therefore is inlined at point of use in the second module, and
there are no references to MLast in the generated .cmo file.

Best regards,

• Xavier Leroy

Comment author: administrator

Normal behaviour, see follow-up for explanations.

Comment author: administrator

Xavier Leroy writes:
Date: Wed, 20 Jul 2005 15:23:17 +0200

Generally speaking, when a program dynlinks a module A that references
a module B (B = MLast in your example), you must ensure that an
implementation of B is available, e.g. by linking B.cmo statically with
the program. Otherwise, you'll get "undefined global B" errors.

OK, then I would like to turn this into a feature wish: Please
provide an implementation mLast.cmo in the next distribution. It
is as easy as

ocamlc -c -pp "camlp4r -impl" -impl mLast.mli

although it might be preferably to have a save object file
mLast.cmo.

Bye,

Hendrik