Re: [Caml-list] Link a .so/.dll dynamically

["Stéphane Glondu" <steph@glondu.net>]

On 09/15/2011 10:49 AM, Romain Bardou wrote:
> Thanks, I tried the following combinations (with the bytecode version,
> not the native one):
> 
> -cclib -l$(DLLPATH)$(DLLNAME)$(DLLEXT)
> -cclib -L$(DLLPATH) -cclib -l$(DLLNAME)$(DLLEXT)
> -L$(DLLPATH) -cclib -l$(DLLNAME)$(DLLEXT)
> -cclib -l$(DLLPATH)$(DLLNAME)
> -cclib -L$(DLLPATH) -cclib -l$(DLLNAME)
> -L$(DLLPATH) -cclib -l$(DLLNAME)
> 
> Where $(DLLPATH) is the full path to my driver, such as /usr/lib/,
> $(DLLNAME) is driver file name without the extension, such as driver,
> and $(DLLEXT) is the extension, such as .so, such that the full .so path
> is /usr/lib/driver.so.

"-l$(DLLNAME)" refers to "lib$(DLLNAME).so". It is to be used with
system shared libraries that use that convention. If you want to link to
something not using this convention, using the full path (without -l/-L)
might work on Linux, but keep in mind that not using lib$(DLLNAME).so
might be on purpose (e.g. to suggest that this .so should be dlopen()-ed
and not ld-linked).

> None of them works; I still get the "undefined symbol" error. The option
> does appear with ocamlobjinfo though. For instance, here is the result
> of ocamlobjinfo on the .cma using the last command:
> 
> Extra C object files: -lcryptoki -ldriver
> Extra C options: -L/usr/lib/
> Extra dynamically-loaded libraries: -lcryptoki
> 
> Shouldn't the -ldriver option appear in the extra dynamically-loaded
> libraries as well?

Where does cryptoki come from?

> I might try Jeremie's more direct approach if everything else fails.

Actually, I should have read more carefully your first mail... Jeremie's
(and Daniel's) approach are clearly the way to go: write a C stub around
dlopen() once and for all. I was instead thinking about drivers written
in OCaml that were using system shared libraries in my replies.


Cheers,

-- 
Stéphane