- Seemingly fix linking of plugins with shared libvlc on Win32
authorRémi Denis-Courmont <rem@videolan.org>
Sun, 19 Feb 2006 09:03:58 +0000 (09:03 +0000)
committerRémi Denis-Courmont <rem@videolan.org>
Sun, 19 Feb 2006 09:03:58 +0000 (09:03 +0000)
commit7a79cedebf6e0bde2e6a3a0be818593a5d7b35d2
tree1c452576daa9ed1b3e4757e31507d0d57d8c361f
parent9dab2c80dd488916556048e2c3ae14b3e50e2c3e
- Seemingly fix linking of plugins with shared libvlc on Win32
- Hopefully the same on Darwin

!!! BIG FAT WARNING !!!
On architectures where you need to resolve all symbols when
linking a shared library, libvlc must be built before the plugins, so
that they can resolve symbols from the libvlc API. Also, the "builtins"
must be built before libvlc (regardless of the architecture or use of
shared libvlc). However, our build system currently builds all modules,
whether builtins or plugins, then libvlc and then vlc.

Obviously, we could swap the build orders, so that libvlc gets built
before modules/ but that will only work if there is no buitins modules.
I'm not too keen on the idea of recursing twice within the modules/
subdirectories (once for builtins, and once for plugins). Until the
issue is settled, here is how to build and test the shared libvlc on
Win32:

1/ run configure with --enable-shared-libvlc
2/ build all built-in modules (or disable them all) one by one,
3/ make libvlc.dll
4/ make
bootstrap