It was added in mingw-w64 in [1] which is in v6, our minimum version.
We don't need to have it defined in UWP builds as we don't use winvlc.c.
[1] 36d7b92bbc
winvlc.c uses API's not available in UWP:
- SetProcessMitigationPolicy
- SetProcessDEPPolicy
- SetDllDirectory
- SetDefaultDllDirectories
- MessageBox
GetCommandLine is allowed but not in mingw-w64 yet.
Interfaces from libvlc were started from the main thread directly. But
UI inserting their own event loop inside the main runloop like Qt were
taking over the interface insertion. It was preventing other interfaces
to load correctly, required dedicated code to handle the startup in the
Qt interface and it was not possible to exit the interface correctly.
By moving the creation of the interfaces in a dedicated thread, we can
ensure all UI are created and destroyed correctly, but the macosx
interface must now dispatch its own creation into the main thread to
match Cocoa requirement on main thread usage for UI components.
Note that libvlc_new itself must be moved to the intf_queue given that
it starts additional extraintf.
The macosx interface must now start its own NSApp inside the main loop,
via a dispatch call, which simplify the main loop into running the
default main loop.
Setting the target DEPENDENCIES might lead to confusing behaviour where
dependencies added to LDADD are not propagated correctly. The automake
manual suggest using `EXTRA_%_DEPENDENCIES` when the goal is to augment
the automake-generated `%_DEPENDENCIES` instead.
It's restricting available code to Windows XP that we don't support.
The value should be the minimum OS we support. It's automatically
picked based on _WIN32_WINNT.
The Frameworks folder was missing in the rpath, leading to Frameworks
like Sparkle requiring change of the install_name after it was built
instead of just using rpath properly.
This gets rid of a prefix inside our build dir, and uses DESTDIR
when installing the content. This way, the install directory
can be reused for further packaging introduced in the next commits.
This enables us to just run the vlc executable from an installed
directory like on any other POSIX installation. All modules should
work, apart the macOS interface module which requires the bundle
structure.
For posix-style installations, use the defined directories
for libraries and data.
With that, running vlc from the install dirs works fine in principle.
What is left to do currently is to adapt the RPATH to find the
libvlc libraries.
This prevents these executables from linking to a shared
libssp-0.dll if both a static and shared version is available
of this library.
Since these refer to the dynamically linked libvlc via libvlc.la,
it will still pick up the correct shared version of those, instead
of refusing to link to a dynamic library (as it does for any
library specified via -l<name>).
The same use of -Wc,-static is present in a few other Makefile.am
already.
