Browse thread
Dynamic loading of native code : what about librairies and packs ?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Alain Frisch <alain@f...> |
| Subject: | Re: [Caml-list] Dynamic loading of native code : what about librairies and packs ? |
Pierre-Loïc Garoche wrote: > ** First: what about external libraries ? > Could you detail the behavior of the linking process of cmxs file with > respect to dependancies. > > If I understand well any library used to compile cmx files should be > - either know by the software dynamically loading the plugin, > - or its cmxa should be passed as argument of ocamlopt -shared command. > > But what is the difference between: > ocamlopt.opt -shared mylib.cmxa xxx.cmx yyy.cmx -o target.cmxs > and > ocamlopt.opt -shared -linkall mylib.cmxa xxx.cmx yyy.cmx -o target.cmxs > > Both seems to work similarly on my example (no differences between > resulting files). The -linkall forces all the modules in the included libraries (here, mylib.cmxa) to be included in the .cmxs file, even if they are not explicitly used by other linked modules. This option is generally useless when linking cmxs files, unless the .cmxs file is loaded in non-private mode, and you want subsequently loaded .cmxs files to be able to access any module in the libraries. (Typically, if you turn mylib.cmxa into a mylib.cmxs, without any other module, you want -linkall.) > ** Second: how about packs ? As far as I can tell, packing and creating cmxs files are orthogonal features: they don't overlap and they don't have bad interactions. It is ok to put in cmxs files a module produced by -pack. I think it is also ok to put modules compiled with -for-pack, but I don't see why you would do that. Regards, Alain