[vlc-devel] Building statically

[Rémi Denis-Courmont]

On Mon, 27 Sep 2010 10:46:00 +0200, "Pierre d'Herbemont"
<pdherbemont at free.fr> wrote:
> As you may know, on iOS you can't dynamically link to your own
> libraries, nor dlopen modules. The sandbox prevents you from doing
> that.

As a side note, that's a pretty damn stupid restriction. If the plugins are
stored in your private directory that no other application can touch, this
does not provide any security to anyone (user, device vendor, application
vendor or operator). I can imagine why you should not be able to dlopen()
other app's objects but that's different.

> Here is what we've been doing for work arounding this:
> - Reenable --disable-shared in the configure.

This is blocked to prevent people shooting themselves in the feet. I don't
want to re-enable it as such.

> - Add libvlc_new_with_plugins(), which takes a list of plugins to
> statically initialize.

I don't see the point, except making the programmer's life more miserable.
If you link statically, the list of plugins is by definition static. So
what's the point of overriding it at run-time?

> - Some dummy hacking in src/ to make the old static plugin
> initialization reachable.

AFAIK, you need src/ to be built before modules/, so I don't see how that
would work. To build a static libvlc, with static plugins, you'd need to
merge the archive files after both src/ and modules/ have been gone
through.

In any case, since there is no single list of plugins anywhere in the build
system, I have to suspect that none of this is going to work.

> In practice it means that libvlc client can statically link libvlc,
> libvlccore and the plugins it wants to.

It's not that simple. Plugins needs to link back into the same libvlc that
reinstantiates them. This is caused by some static variables here and there
within libvlc. Otherwise, we get run-time crashes.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis