[Caml-list] Dynamic Linking Bug

[Caml-list] Dynamic Linking Bug

[Warp]

Hi all.
Here's some bug
It comes when trying to Dynlink a CMA build with flags :
> -cclib -lmylib -dllib -lmylib
(these allow static and dynamic linking)

When I compile and run a program with
> ocamlc mylib.cma myprog.ml
it works.

But when I use the following into myprog.ml ( and compile it without the
CMA )
> Dynlink.loadfile "mylib.cma"
it prints the Win32 error message "Dynamic library not found", which is
quite annoying because the name of the DLL is missing. Seems like the
dynlink_open_lib should fail with more informations (at least under Win32 :
caml_dlerror does not include the name of the module ).
So i did make it fail with the name of the library Dynlink is trying to load
, and it is "-lwin32.dll" ( seems like Dynlink doesn't like -l notation ).

Another problem with dynamic linking is that it can't be used with "-custom"
mode. When you write a DLL, you need to use caml functions to register
roots, allocations, etc... To enable access to theses functions, you need to
link with ocamlrun.lib which contains links to ocamlrun exported functions.
So when your runtime is not ocamlrun, the calls to caml functions crash. An
issue would be to have a ocamlrun.lib which links to the loading runtime. I
would be glad to know if the OCaml Team is working on that problem, or is it
"case closed" ?

Thanks

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamic Linking Bug

[Harry Chomsky]

> It comes when trying to Dynlink a CMA build with flags :
> > -cclib -lmylib -dllib -lmylib
> > Dynlink.loadfile "mylib.cma"
> it prints the Win32 error message "Dynamic library not found", which is
> quite annoying because the name of the DLL is missing. Seems like the
> dynlink_open_lib should fail with more informations (at least under Win32
:
> caml_dlerror does not include the name of the module ).
> So i did make it fail with the name of the library Dynlink is trying to
load
> , and it is "-lwin32.dll" ( seems like Dynlink doesn't like -l notation ).

This looks like a bug in dynlink.ml.  The line:
        Dll.open_dlls lib.lib_dllibs
should be changed to something like this:
        Dll.open_dlls (List.map Dll.extract_dll_name lib.lib_dllibs)

Can this fix be incorporated into the next OCaml release?

> Another problem with dynamic linking is that it can't be used with
"-custom"
> mode. When you write a DLL, you need to use caml functions to register
> roots, allocations, etc... To enable access to theses functions, you need
to
> link with ocamlrun.lib which contains links to ocamlrun exported
functions.
> So when your runtime is not ocamlrun, the calls to caml functions crash.

This is a problem with "-custom", and it is also a problem with
"-use-runtime".  Also it applies to the standard load-time dynamic linking
as well as runtime use of Dynlink.  Right now OCaml programmers have two
choices:

1) Use dynamic linking along with the standard ocamlrun.exe; or
2) Use a custom runtime, either with "-custom" or with "-make-runtime" +
"-use-runtime", and statically link in all the libraries you'll need.

It would be nice if there were a way to mix and match between these two
approaches.  I'm also curious whether anyone on the OCaml team sees this as
a possible future enhancement, or if it's just not possible.

Specifically, since we're using OCaml to build Windows applications, we want
to have our OCaml runtime use the "windows subsystem" instead of the
"console subsystem".  This is easy if we link using "-custom", but we
haven't found a good way to do it with dynamic linking.  Our only option is
to keep two versions of ocamlrun.exe with the same name in different
directories, one flagged for the console subsystem and one flagged for the
windows subsystem, and change the search path to find one or the other
depending which kind of OCaml program we want to run.  It would be much
nicer if we could name the windows-subsystem runtime "ocamlrunw.exe"
instead -- but then DLLs won't find it.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners