2011/5/24 Stéphane Glondu <glo...@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 -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikoyj0_kv-za8butwkum6nnp_j...@mail.gmail.com