[vlc-devel] Building statically

[Pierre d'Herbemont]

2010/9/29 Rémi Denis-Courmont <remi at remlab.net>:
>
> On Mon, 27 Sep 2010 10:46:00 +0200, "Pierre d'Herbemont"
> <pdherbemont at free.fr> wrote:
>> 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.

Ok, I'll add a new --enable-static-modules, or something like this.

>> - 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?

The point is, libvlc doesn't get to be linked with the plugins. Only
the final executable is. More flexibility and such... But the real
reason is that it requires no hack in the build system. I would be
happy to get libvlc (not libvlccore) as the real container, but that's
unnecessary pain for what we wanted to achieve.

>> - 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.

See previously, we don't link libvlc to the plugins.

> 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.

It does, here, else how would you expect the app to be on the AppStore :)
But that's a real point, the client app has to know which plugins it
wants to link to.

>> 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.

You meant libvlccore right? Anyway, the build system isn't touched
with this hack and can live outside vlc.git I believe.

Pierre.