GitLab

Only allow static plugins if vlc binary is not built

Also, __USE_UNIX98 is a libc-internal definition. The build system is
not supposed to define that directly (we have _GNU_SOURCE).

I don't this abomination to leak through the stable LibVLC interface.
To link statically, modules should be linked into LibVLC instead.

And then, there is no need to reintroduce the old "builtin" vlc-config
type if all modules are built the same. In prehistoric times, the
distinction was needed because some modules were static and some not.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Left-over from pre-libtool era

We can now store other architecture-dependant files in $(pkglibdir)
(and without bugging the plugins scan).

This is just pedantic. Nobody links against plugins anyway.

This reverts back to 0.9 (and --enable-libtool 0.8.6) state. This
should fix bindings and web plugins, without hacks. However, this will
require relinking all VLC plugins whenever libvlccore changes.

I kept include files to ../vlc otherwise #include syntax would break

Now, it's up to changing PKGDIR="vlc" to PKGDIR="vlc-1.0".
We just need to decide.

We really want plugins to resolve their VLC symbols against the already
loaded LibVLC core, rather than with their own version of it.
Performance benefit should be neglectible, if any.
Still, this will "fix" the plugin crash with static LibVLC builds (or
generate a due link-time error). Anyway, this is one step toward
supporting any form of static linking again.

We don't need to invoke make twice in every directory, and we don't need
the awful libtool install kludge anymore.

...in addition to vlc-config

Less escaping, less stuff that Makefile.am's depend on