[vlc-devel] reenabling java bindings

[Rémi Denis-Courmont]

Le vendredi 12 décembre 2008 17:08:49 Olivier Aubert, vous avez écrit :
> With your approach, all other mentionned systems (java bindings, python
> bindings, mozilla plugin) should have to explicitly load libvlcore with
> something like
>
> if (!dlopen ("libvlccore.so", RTLD_NOW | RTLD_GLOBAL))
>   printf ("\n%s\n", dlerror());

Whether this is actually needed depends on how libvlc is linked. Normal LibVLC 
applications (not just plain VLC) don't need this. I am not going to argue to 
the fact that this does not look very clean.

However, in my opinion, linking against libvlccore while _assuming_ that it is 
(the exact same) libvlccore that is loading the plugin is just as ugly. It 
happens to put the ugliness in a place where the LibVLC API user won't see 
it, but the VLC builder/packager will.

Maybe there is a way to remove all harmful static data from libvlccore, etc 
such that the ugly linking assumption is not needed anymore, but I am 
suspicious about the feasibility.

> (with an additional #define to use .dll instead of .so for windows, etc).

Does Windows need this? I think Windows does not support unresolved symbols, 
so we MUST link plugins against libvlccore anyway.

> so that libvlccore symbols are available for subsequently loaded vlc
> modules. It is not undoable, but looks hackish to me: since plugins use
> symbols from libvlccore, we should simply link them with libvlccore, not
> rely on user code to do that.

I still claim it's not uglier than linking against libvlccore. On top of that, 
on Linux, this gives the opportunity to dlopen(RTLD_NOLOAD) which brings 
reasonable assurance that we are not opening a different libvlccore than the 
one actually in use.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary