English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Native Module Linking
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-11-10 (01:47)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] Native Module Linking
From: "Nicolas Cannasse" <warplayer@free.fr>

> I have a project that is structured like this :
> - a library with one Entry module and several Plugins
> - an application using the library.
> In the application I'm doing the following :
> open Entry;
> open Plugin1;
> open Plugin2;
> ....
> (* use "Entry" *)
> Plugins are using Entry, and application is only activating plugins with
> "open" (in order to ensure they're linked).
> On windows everything works well but looks like on Linux some configurations
> are not linking the plugins (at least in opt mod : ocamlopt myLib.cmxa
> myApp.ml ). And I can't use the -linkall because I'm using other libraries
> that I want to partially link . Is this a bug, a feature, or a
> misunderstanding ?

Your first assumption is wrong: open is completely unrelated to what
will be linked or not. Or at least it is not supposed to.
To force linking a module, one of its members should be used.
Fo instance, using "include".
I have no idea why it works on windows...

If you want to force a library to be linked monolythically, an option
is to make it into a package (automatically or by hand).

By the way, initialization order is well-defined: it is the order of
the files given on the command line, and inside archives the order
when the archive was created.

   ocamlc -a -o mylib.cma a.cmo b.cmo c.cmo
   ocamlc -o myprog d.cmo mylib.cma e.cmo
when e.cmo requires A and C will result in the initialization order
   D A C E
Nothing strange there.

Jacques Garrigue