Shared libraries from caml

Shared libraries from caml

[Leszek Holenderski]

Hi Camlers,

Is there any way to produce a sunos and/or solaris shared library from a
caml module? Preferably in Caml Special Light, but Objective Caml will also
do.

In fact, I'm interested in a more specific problem. Could I use csl or
ocaml to produce input for the Tcl "load" command? Has anybody tried it
yet?

Cheers,
Leszek

Re: Shared libraries from caml

[Xavier Leroy]

> Is there any way to produce a sunos and/or solaris shared library from a
> caml module? Preferably in Caml Special Light, but Objective Caml will also
> do.
> In fact, I'm interested in a more specific problem. Could I use csl or
> ocaml to produce input for the Tcl "load" command? Has anybody tried it
> yet?

Dynamic linking of Objective Caml modules inside an Objective Caml program
is not completely impossible, but requires a lot of work. There are
global tables in the runtime that collect infos on all the Caml modules
linked in the application. These tables are currently fixed-size and
built at link-time. In the presence of dynamic linking, these would
need to be made extensible and updated correctly after dynamic linking.

Dynamic linking of O'Caml modules inside an arbitrary program (e.g. tcl)
is even harder. The whole Objective Caml runtime needs to be embarked
somehow. Also, if you don't have no control over the program that does
the dynamic linking, it's very hard to perform the correct
initializations, both of the module and of the runtime system itself.

It would be much easier to link Tcl into an O'Caml program that has
already all O'Caml modules statically linked. The callback Tcl -> O'Caml
is not too hard to do, see CamlTk4 for an example.

- Xavier Leroy

Re: Shared libraries from caml

[Leszek Holenderski]

>> Is there any way to produce a sunos and/or solaris shared library from a
>> caml module? Preferably in Caml Special Light, but Objective Caml will also
>> do.
>> In fact, I'm interested in a more specific problem. Could I use csl or
>> ocaml to produce input for the Tcl "load" command? Has anybody tried it
>> yet?

[Xavier Leroy wrote:
>Dynamic linking of O'Caml modules inside an arbitrary program (e.g. tcl)
>is even harder...
]

Bad news, but this is what I've expected. Anyway, thanks for your answer.

[Xavier Leroy wrote:
>It would be much easier to link Tcl into an O'Caml program that has
>already all O'Caml modules statically linked. The callback Tcl -> O'Caml
>is not too hard to do, see CamlTk4 for an example.
]

It doesn't help. The whole problem is to call O'Caml code from *standard*
Tk wish, and not the *extended* one. My real problem is as follows.

I've written some Tk application which uses O'Caml code to speed things up.
The Caml-Tk combination I use is based on the same protocol as CamlTk4. As
a consequence, my Tk application needs to be interpreted by an extended Tk
wish (the one which contains my Caml code). Unfortunately, this means that
in order to distribute my application I would have to distribute the
extended wish as well.

Anyone who has tried to distribute such an extended Tk wish in binary form
knows that it's virtually impossible, due to "unprecedented flexibility"
(read "unpredictable and messy configurations") of Unix. The extended wish
must be recreated by a user of my program and this step needs at least
Caml's linker, and in the worst case, the whole Caml environment. Thus,
installing my application on another site becomes a serious problem for a
casual user, even with the wonderful, almost fully automatic, installation
scripts for O'Caml.

If I could prepare my Caml code as a shared library then standard Tk wish
could load it dynamically and I'd only need to distribute the library, not
forcing the user to install the whole Caml environment just to play with my
app.

Cheers,
Leszek