Re: Automatic dependencies for shared modules

[Romain Beauxis <toots@rastageeks.org>]

2011/5/24 Stéphane Glondu <glondu@debian.org>:
> Le 24/05/2011 04:04, Romain Beauxis a écrit :
>> Basically, we want optional plugins, e.g. liquidsoap-plugins-sdl,
>> which depends only on the corresponding C libraries, in this case the
>> libsdl, but no ocaml module. [...]
>
> The error message is legitimate in this case. Actually, this specific
> case motivated the test: it can be broken to load several times the same
> OCaml module, which happens when plugins have common dependencies (e.g.
> libraries used by the main program and plugins... this is basically the
> diamond inheritance problem).

I did not know that, thanks.
However, this is irrelevant to this specific issue: sdl is not loaded
elsewhere in the program, only the plugin will load it..

>> However, not passing those dependencies at link time is absolutely
>> impractical: this would mean that liquidsoap would have to load all of
>> them in the right order.. while they do not even exist in the current
>> package (e.g. sdl.cmxs)...
>
> You can use findlib (the OCaml library) for that, and make the
> dependencies build plugins.

Hmm.. You mean build a cmxs for sdl at build-time? First, this would
give the same error and it would also increase the complexity of the
dynamic loading, in order to resolve dependencies etc..

>> Also, linking liquidsoap with sdl is not the idea: we want precisely
>> to reduce the number of shared libraries linked with the binary by
>> default and move those to the plugins.
>
> Of course.
>
>> Note that because of this bug I have not been able to check whether
>> the dependencies on the C libraries are correctly extracted but I
>> believe they are.
>
> This is not a bug, IMHO. The impracticality comes from the OCaml way of
> doing things. If you still want to do your way (which I think is
> broken), just don't call dh_ocaml (C dependencies are created by
> dpkg-shlibdeps).

Unfortunately, I would need to use dh_ocaml at least for bytecode
modules, to get the right dependency against the corresponding
implementation..

All in all, I still do not understand your point. What is wrong with a
plugin containing module Foo and being the only one loading this unit
in the whole program?

Romain