[vlc-devel] reenabling java bindings
rem at videolan.org
Tue Dec 16 20:07:48 CET 2008
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.
More information about the vlc-devel