[vlc-devel] [PATCH 2/2] configure: split dynamic plugins from dynamic loader

[Remi Denis-Courmont]

Le 2020-03-06 19:36, Alexandre Janniaux a écrit :
> You confused me, is it the fact that we can use
> out-of-tree plugins, or the fact this is the whole point
> of this split, or that my answer doesn't match yours that
> doesn't make any sense to you?

You can't load dynamic plugins without the dynamic loader, and the 
dynamic loader is useless without dynamic plugins. As such, it's 
pointless to distinguish the two. So this patch is mostly pointless code 
churn.

There's likewise not much point distinguishing shared builds and the 
dynamic loader. The loader depends on shared builds by design on one 
hand. On the other hand, there're no particular reasons to make shared 
builds without the loader.

>> You can't load dynamic plugins without the dynamic loader, and you 
>> can't use
>> the dynamic loader without dynamic plugins to load with it.
> 
> To put thing clear:
> 
> You have two types of loaders:
> 
> + static loader (vlc_static_modules)
> + dynamic loader (dlopen)
> 
> You have two types of plugins:
> 
> + static plugins
> + dynamic plugins

That's poor nomenclature and poor classification.

There are two different ways to load a module:
- statically (at the moment, via vlc_static_modules),
- dynamically (via dlopen, and at the moment dlsym).

There are also two different ways to link the module with the plugin 
API, via build-time linking or run-time linking. However you can't 
build-time link a dynamic plugin so there's really three possibilities, 
not four. (Then again, before libtool, we used to have a horrible way 
around that.)

Finally, there are also two ways to build libvlc(core), shared or 
static. But if you build them as static, then you can't link modules 
dynamically.

In reality, this leads to four different possibilies:

A) shared libvlccore loading dynamically linked shared module.
B) shared libvlccore loading dynamically linked static module,
C) shared libvlccore loading statically linked static module,
D) static libvlccore loading statically linked static module.

In case A, the module is its own shared object. In case B, the module is 
in a shared object that loads libvlccore (presumably the main 
executable). In case C and D, the module has to be in the same object as 
libvlccore.

With --enable-shared, we support A and B at the moment. C cannot be 
handled by the current build system, but that's got nothing to do with 
*this* patch.

With --disable-shared, we support D, or rather we let an overlying build 
system support D. And there's nothing else that can be supported, so 
there's nothing to do.

> Then, those are currently available when building dynamic
> libraries (--enabled-shared) on ELF:
> 
> + static and dynamic loader with dynamic plugins

In a sense.

> But when building with --disable-shared, we have static
> plugins and static loader only.

There are no ways around that as explained multiple times.

> It makes sense only because you don't have dynamic libraries
> to link plugin to, but as you have the static ones, nothing
> prevent your from creating them by:
> 
> + creating libvlccore.so by linking libvlccore.a, the
>   static.o stub declaring vlc_static_modules, and all the
>   different plugins archive libraries.

You can already do that, and that's not giving you dynamic plugins.

> + creating libvlc.so by linking libvlc.a and libvlccore.so
> 
> + linking out-of-tree plugin with the libvlccore.so
> 
> Does it make more sense to you?

No. You can already do those things with the current system, and nothing 
justifies this patch in that regard.

-- 
Rémi Denis-Courmont