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

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

[Romain Bardou]

Hello Caml-List,

I need to write a program which handles several devices. Each device has 
a .so (linux) or .dll (windows) driver. Each of these DLL share the same 
API, defined in C headers (api.h).

Here is what I figured I should do.
- Write a binding for the library.
   * OCaml part: mylib.ml, with externals.
   * C part: wrapper.c, implementing the externals.
     - Which itself includes api.h and may use the functions of the API.
- Dynamically load this library using Dynlink.
Later, the Mylib module will register each function of the API so the 
program can call them, but that's not the issue (although if there is a 
simpler way please tell).

So far, here is what I have achieved: I managed to dynamically load a 
Mylib module with externals in wrapper.c, but this wrapper.c file does 
not include nor use the API (it just prints some text on standard 
output). Here is how I compile the program:
	ocamlc -c wrapper.c
	ocamlc -c mylib.ml
	ocamlmklib wrapper.o mylib.cmo -o mylib
	ocamlc -c main.ml
	ocamlc dynlink.cma main.cmo -o main
	CAML_LD_LIBRARY_PATH=. ./main
The main.ml file uses Dynlink to load "mylib.cma". The 
CAML_LD_LIBRARY_PATH environment variable is needed for some reason, or 
the dynamic linker cannot find dllmylib.so.

My first problem is: I tried something similar for native code (using 
ocamlopt instead of ocamlc, .cmx instead of .cmo and .cmxa instead of 
.cma) but ocamlmklib fails with the following error:
	/usr/bin/ld: wrapper.o: relocation R_X86_64_32 against `.rodata' can 
not be used when making a shared object; recompile with -fPIC
	wrapper.o: could not read symbols: Bad value
	collect2: ld returned 1 exit status
I have absolutely no idea what this means, I'm really confused here and 
Google does not help.

My second, more important problem is: how do I link with the .so / .dll 
of my device? Obviously, once I use functions declared in api.h, the .so 
needs to be loaded or I get the "undefined symbol" error. Assume I want 
to link with /usr/lib/toto.so. How should I modify my compilation 
process to ensure that this driver will be dynamically loaded when Mylib 
is dynamically linked with Dynlink? I tried various combinations of 
parameters for ocamlmklib and none worked.

A third question will be: I'm testing this under Linux with .so files, 
will there be additional problems on Windows with .dll files?

Thank you for your help. As you can see, I'm a little confused about 
those things.

-- 
Romain Bardou

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

[Benedikt Meurer]

On Sep 14, 2011, at 17:00 , Romain Bardou wrote:

> My first problem is: I tried something similar for native code (using ocamlopt instead of ocamlc, .cmx instead of .cmo and .cmxa instead of .cma) but ocamlmklib fails with the following error:
> 	/usr/bin/ld: wrapper.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
> 	wrapper.o: could not read symbols: Bad value
> 	collect2: ld returned 1 exit status
> I have absolutely no idea what this means, I'm really confused here and Google does not help.

The error messages already includes the answer, you need to pass -fPIC to the C compiler when compiling wrapper.c, i.e.

$ gcc -c -fPIC -o wrapper.o wrapper.c

> Romain Bardou

HTH,
Benedikt

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

[Romain Bardou]

Le 14/09/2011 17:09, Benedikt Meurer a écrit :
>
> On Sep 14, 2011, at 17:00 , Romain Bardou wrote:
>
>> My first problem is: I tried something similar for native code (using ocamlopt instead of ocamlc, .cmx instead of .cmo and .cmxa instead of .cma) but ocamlmklib fails with the following error:
>> 	/usr/bin/ld: wrapper.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
>> 	wrapper.o: could not read symbols: Bad value
>> 	collect2: ld returned 1 exit status
>> I have absolutely no idea what this means, I'm really confused here and Google does not help.
>
> The error messages already includes the answer, you need to pass -fPIC to the C compiler when compiling wrapper.c, i.e.
>
> $ gcc -c -fPIC -o wrapper.o wrapper.c
>
>> Romain Bardou
>
> HTH,
> Benedikt

Thanks for your quick answer.

Actually I tried adding the -fPIC option like this:

	ocamlopt -c -ccopt -fPIC wrapper.c
	ocamlopt -c mylib.ml
	ocamlmklib wrapper.o mylib.cmx -o mylib
	ocamlopt -c main.ml
	ocamlopt dynlink.cmxa main.cmx -o main
	CAML_LD_LIBRARY_PATH=. ./main mylib.cmxa

But when Dynlink.load is called, it fails with the following error:

	error loading shared library: /home/.../mylib.cmxa: invalid ELF header

I'm thinking this is because the .cmxa has not been compiled with the 
-shared option, but I don't know how to tell ocamlmklib to compile with 
the -shared option.

Cheers,

-- 
Romain Bardou

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

[Benedikt Meurer]

On Sep 14, 2011, at 17:56 , Romain Bardou wrote:

> Le 14/09/2011 17:09, Benedikt Meurer a écrit :
>> 
>>> My first problem is: I tried something similar for native code (using ocamlopt instead of ocamlc, .cmx instead of .cmo and .cmxa instead of .cma) but ocamlmklib fails with the following error:
>>> 	/usr/bin/ld: wrapper.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
>>> 	wrapper.o: could not read symbols: Bad value
>>> 	collect2: ld returned 1 exit status
>>> I have absolutely no idea what this means, I'm really confused here and Google does not help.
>> 
>> The error messages already includes the answer, you need to pass -fPIC to the C compiler when compiling wrapper.c, i.e.
>> 
>> $ gcc -c -fPIC -o wrapper.o wrapper.c
> 
> Thanks for your quick answer.
> 
> Actually I tried adding the -fPIC option like this:
> 
> 	ocamlopt -c -ccopt -fPIC wrapper.c
> 	ocamlopt -c mylib.ml
> 	ocamlmklib wrapper.o mylib.cmx -o mylib
> 	ocamlopt -c main.ml
> 	ocamlopt dynlink.cmxa main.cmx -o main
> 	CAML_LD_LIBRARY_PATH=. ./main mylib.cmxa
> 
> But when Dynlink.load is called, it fails with the following error:
> 
> 	error loading shared library: /home/.../mylib.cmxa: invalid ELF header
> 
> I'm thinking this is because the .cmxa has not been compiled with the -shared option, but I don't know how to tell ocamlmklib to compile with the -shared option.

$ ocamlmklib -ldopt -shared wrapper.o mylib.cmx -o mylib

> Romain Bardou

Benedikt

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

[Romain Bardou]

> $ ocamlmklib -ldopt -shared wrapper.o mylib.cmx -o mylib

I tried and I still get the same "invalid ELF header" message.

I also tried :
	ocamlmklib -ocamlopt "ocamlopt -shared"
but then ocamlopt complains that it has been called with too many -a, 
-shared, ... arguments.

According to the man page, I think -ldopt passes the option not to 
ocamlopt but to the "shared linker" (ld ?).

Thanks again for your time,

-- 
Romain Bardou

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

[Stéphane Glondu]

On 09/14/2011 05:56 PM, Romain Bardou wrote:
> [...]
>     ocamlopt -c -ccopt -fPIC wrapper.c
>     ocamlopt -c mylib.ml
>     ocamlmklib wrapper.o mylib.cmx -o mylib
>     ocamlopt -c main.ml
>     ocamlopt dynlink.cmxa main.cmx -o main
>     CAML_LD_LIBRARY_PATH=. ./main mylib.cmxa
> 
> But when Dynlink.load is called, it fails with the following error:
> 
>     error loading shared library: /home/.../mylib.cmxa: invalid ELF header
> 
> I'm thinking this is because the .cmxa has not been compiled with the
> -shared option, but I don't know how to tell ocamlmklib to compile with
> the -shared option.

You can turn the .cmxa generated by ocamlmklib into a .cmxs by calling
(for example):

  ocamlopt -shared -I . -linkall -o mylib.cmxs mylib.cmxa

The .cmxs should then be loadable by Dynlink.load.


Cheers,

-- 
Stéphane

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

[Jérémie Dimino]

Le mercredi 14 septembre 2011 à 18:03 +0200, Romain Bardou a écrit : 
> > $ ocamlmklib -ldopt -shared wrapper.o mylib.cmx -o mylib
> 
> I tried and I still get the same "invalid ELF header" message.
> 
> I also tried :
> 	ocamlmklib -ocamlopt "ocamlopt -shared"
> but then ocamlopt complains that it has been called with too many -a, 
> -shared, ... arguments.

cmxa cannot be loaded dynamically, you need to create a cmxs from the
cmxa with the following command:

  ocamlopt -shared -linkall foo.cmxa -o foo.cmxs

and then load the cmxs dynamically with Dynlink.

-- 
Jérémie

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

[Romain Bardou]

Le 14/09/2011 18:07, Stéphane Glondu a écrit :
> On 09/14/2011 05:56 PM, Romain Bardou wrote:
>> [...]
>>      ocamlopt -c -ccopt -fPIC wrapper.c
>>      ocamlopt -c mylib.ml
>>      ocamlmklib wrapper.o mylib.cmx -o mylib
>>      ocamlopt -c main.ml
>>      ocamlopt dynlink.cmxa main.cmx -o main
>>      CAML_LD_LIBRARY_PATH=. ./main mylib.cmxa
>>
>> But when Dynlink.load is called, it fails with the following error:
>>
>>      error loading shared library: /home/.../mylib.cmxa: invalid ELF header
>>
>> I'm thinking this is because the .cmxa has not been compiled with the
>> -shared option, but I don't know how to tell ocamlmklib to compile with
>> the -shared option.
>
> You can turn the .cmxa generated by ocamlmklib into a .cmxs by calling
> (for example):
>
>    ocamlopt -shared -I . -linkall -o mylib.cmxs mylib.cmxa
>
> The .cmxs should then be loadable by Dynlink.load.

Thanks, this solves the "native" part of my problem ! Now I need to 
figure out how to link this .so file.

-- 
Romain Bardou

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

[Jérémie Dimino]

Le mercredi 14 septembre 2011 à 17:00 +0200, Romain Bardou a écrit : 
> Hello Caml-List,
> 
> I need to write a program which handles several devices. Each device has 
> a .so (linux) or .dll (windows) driver. Each of these DLL share the same 
> API, defined in C headers (api.h).
> 
> Here is what I figured I should do.
> - Write a binding for the library.
>    * OCaml part: mylib.ml, with externals.
>    * C part: wrapper.c, implementing the externals.
>      - Which itself includes api.h and may use the functions of the API.
> - Dynamically load this library using Dynlink.
> Later, the Mylib module will register each function of the API so the 
> program can call them, but that's not the issue (although if there is a 
> simpler way please tell).

You can also use dlopen and dlsym on unix, and 
LoadLibrary and GetProcAddress on windows.

-- 
Jérémie

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

[Stéphane Glondu]

On 09/14/2011 06:12 PM, Romain Bardou wrote:
> Thanks, this solves the "native" part of my problem ! Now I need to
> figure out how to link this .so file.

You mean, the equivalent of dllmylib.so? There is no such file in native
code: mylib.cmxs will contain the contents of mylib.cmxa and wrapper.o.


HTH,

-- 
Stéphane

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

[Romain Bardou]

Le 14/09/2011 18:34, Stéphane Glondu a écrit :
> On 09/14/2011 06:12 PM, Romain Bardou wrote:
>> Thanks, this solves the "native" part of my problem ! Now I need to
>> figure out how to link this .so file.
>
> You mean, the equivalent of dllmylib.so? There is no such file in native
> code: mylib.cmxs will contain the contents of mylib.cmxa and wrapper.o.
>
>
> HTH,
>

No I mean the driver DLL for which Mylib is the binding. File 
dllmylib.so is linked correctly, but binding.c includes api.h, which is 
implemented in api.so, so I need to link with api.so as well. The whole 
point of my original question is: how can I design the program such that 
this api.so is loaded dynamically, because the user may want to choose a 
different driver everytime, or even change driver during execution.

Cheers,

-- 
Romain Bardou

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

[Stéphane Glondu]

On 09/14/2011 06:42 PM, Romain Bardou wrote:
>>> Thanks, this solves the "native" part of my problem ! Now I need to
>>> figure out how to link this .so file.
>>
>> You mean, the equivalent of dllmylib.so? There is no such file in native
>> code: mylib.cmxs will contain the contents of mylib.cmxa and wrapper.o.
> 
> No I mean the driver DLL for which Mylib is the binding. File
> dllmylib.so is linked correctly, but binding.c includes api.h, which is
> implemented in api.so, so I need to link with api.so as well. The whole
> point of my original question is: how can I design the program such that
> this api.so is loaded dynamically, because the user may want to choose a
> different driver everytime, or even change driver during execution.

That would be a -cclib option passed to ocamlmklib. It embeds a -lXXX
option in the .cmxa that should be visible with a recent version of
ocamlobjinfo. You can check the result by running ldd on the .cmxs file.


Cheers,

-- 
Stéphane

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

[Romain Bardou]

Le 14/09/2011 18:56, Stéphane Glondu a écrit :
> On 09/14/2011 06:42 PM, Romain Bardou wrote:
>>>> Thanks, this solves the "native" part of my problem ! Now I need to
>>>> figure out how to link this .so file.
>>>
>>> You mean, the equivalent of dllmylib.so? There is no such file in native
>>> code: mylib.cmxs will contain the contents of mylib.cmxa and wrapper.o.
>>
>> No I mean the driver DLL for which Mylib is the binding. File
>> dllmylib.so is linked correctly, but binding.c includes api.h, which is
>> implemented in api.so, so I need to link with api.so as well. The whole
>> point of my original question is: how can I design the program such that
>> this api.so is loaded dynamically, because the user may want to choose a
>> different driver everytime, or even change driver during execution.
>
> That would be a -cclib option passed to ocamlmklib. It embeds a -lXXX
> option in the .cmxa that should be visible with a recent version of
> ocamlobjinfo. You can check the result by running ldd on the .cmxs file.
>
>
> Cheers,
>

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.

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?

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

Cheers,

-- 
Romain Bardou

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

[Romain Bardou]

Le 14/09/2011 18:56, Stéphane Glondu a écrit :
> On 09/14/2011 06:42 PM, Romain Bardou wrote:
>>>> Thanks, this solves the "native" part of my problem ! Now I need to
>>>> figure out how to link this .so file.
>>>
>>> You mean, the equivalent of dllmylib.so? There is no such file in native
>>> code: mylib.cmxs will contain the contents of mylib.cmxa and wrapper.o.
>>
>> No I mean the driver DLL for which Mylib is the binding. File
>> dllmylib.so is linked correctly, but binding.c includes api.h, which is
>> implemented in api.so, so I need to link with api.so as well. The whole
>> point of my original question is: how can I design the program such that
>> this api.so is loaded dynamically, because the user may want to choose a
>> different driver everytime, or even change driver during execution.
>
> That would be a -cclib option passed to ocamlmklib. It embeds a -lXXX
> option in the .cmxa that should be visible with a recent version of
> ocamlobjinfo. You can check the result by running ldd on the .cmxs file.
>
>
> Cheers,
>

Out of curiosity I redid the same tests on the native build, and the 
following works :

ocamlmklib -cclib /usr/lib/driver.so wrapper.o mylib.cmx -o mylib

It appears that the library is linked when "ocamlopt -shared" is called 
though, so the library is statically linked in the dynamically linked 
module. Which is fine actually, it does solve my problem.

I guess I don't really need the bytecode version, but if there is a way 
to do it, please satisfy my curiosity ;)

Thanks and cheers,

-- 
Romain Bardou

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

[Stéphane Glondu]

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

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

[Romain Bardou]

Le 15/09/2011 11:20, Stéphane Glondu a écrit :
> 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?

Oups, please replace cryptoki by mylib here :p

(Cryptoki is another name for PKCS#11, which is the API I want to 
implement my bindings for)

>> 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.

Okay then :p

Thanks,

-- 
Romain