This was added ostensibly to fix compilation of the run-time AltiVec
test which was removed in bc146294cf.
Unfortunately, it causes the compiler to emit AltiVec instructions,
such that the executable crashes if AltiVec is not available.
Regression from e48d619555.
This version gives access to `UpnpInit2` for both IPv6 and IPv4.
`UpnpInit` is deprecated since 1.6 and less safe than `UpnpInit2`.
Libupnp 1.8.3 has been out since 2017 and has been widely adopted in
most linux distributions now (available on debian since version 10).
Dropping support for lower versions will allow us to completely remove
`UpnpInit` from the codebase and simplify a lot the netintf selection
code.
This avoids potential compiler optimizations when casting to void** when using
IID_PPV_ARGS or WRL.
If the option is not supported we fail the configure as many important C++
modules may not work as expected due to pointer aliasing. In practice this
should never happen as GCC for mingw-w64 and Clang support this correctly.
Maybe it was OK to keep it in 3.0 but in 4.0 we can't expect to reuse ancient
folders, just to save a luac rebuild.
Also add a nice message when configuring.
This is necessary for Linux-specific getauxval() and associated flags.
In this case, VLC needs AT_HWCAP (and probably AT_HWCAP2 going forward)
to detect CPU features on most architectures.
Allow the configure script to substitute the theme used in the
documentation for Awesome doxygen css from the CI script.
The theme won't be mandatory, but we can change it and inject it for the
production documentation online.
Otherwise it won't compile compatible code.
If protoc is not there we check the version of protobuf we expect so we get the
proper error messages on what's really missing.
Similar to how we force detection of luac there.
We might be using
AC_CHECK_TOOL(PROTOC, protoc, no, [${CONTRIB_DIR}/../bin$PATH_SEPARATOR$PATH])
Which works, but it doesn't keep the full path, so if the PATH is not set in
the environment when using HOST-protoc it doesn't find it. So we either have to
force everyone to add a new item in their PATH or just use the transparent way
that luac is using.
Traditionally the presence of the header file was not considered
sufficient, though this was somewhat forgotten with the prevalence of
pkg-config.
However most libraries have portable headers, while the shared library
is platform-dependent. It is common for the header to be present while
the library is absent with "multilib" installations (i.e. Linux
installation with multiple architectures).
Traditionally the presence of the header file was not considered
sufficient, though this was somewhat forgotten with the prevalence of
pkg-config.
However most libraries have portable headers, while the shared library
is platform-dependent. It is common for the header to be present while
the library is absent with "multilib" installations (i.e. Linux
installation with multiple architectures).
The AX_APPEND_FLAG arguments were reversed, the program was not escaped
from m4 macros, and the function was declared in the body of the main
function, so it just couldn't work.
After fixing this, static module bank is back working normally on
MacOSX.
DeckLinkAPIDispatch.cpp is not available on Windows.
DeckLinkAPI.h is available on all supported platforms.
Allow decklink SDK from the contribs if --with-decklink-sdk is not used.
Co-authored-by: Marvin Scholz <epirat07@gmail.com>
The composition works as follow:
* Both the interface and the video are rendered in an offscreen window (using
X11 composite extension)
* We register to damage event (x11 damage extension) to get notified when the
content of the offscreen video window change. When we receive a damage event
we ask the rendering part of the composition to refresh
* The interface is rendered in the offscreen surface using a RenderControl, when
the interface do render, the composition is asked to refresh
* A dedicated thread is spawned to do the rendering, upon a refresh event it
will take the pictures from the offscreen surface and blend them into the
actual window using X11 render extension. Using a separated thread from Qt
ensure that the rendering of the video will not be stalled if Qt thread is
busy.
* The damage events are listened on a separate X11 connection and on a separate
thread than Qt main thread (here the rendering thread). This allows to receive
theses events independently from Qt (in case the Qt thread is stalled). Note
that it is not possible to peek in qt X11 event queue from a non gui thread as
the QX11Info::peekEventQueue is no longer thread safe since 5.12.
fixes: #25627, #22155
It was necessary for the npapi build (in release/nightly builds) but it should
not be needed anymore since 4c7155f3f1
Many Docker images already provide their own value. Only the LLVM images don't
but they will soon.
After 9e7ed0247d the test for the environment
variable wasn't done properly. Resulting in empty variables (and error messages
during configure).
Fixes#26165
This is packaged everywhere relevant, including Debian 11 (stable).
Fedora 33 and Ubuntu 20.10. (Rolling release distros all have v4
anyways)
Motivation behind this is twofold: besides the obvious code
simplification, this is mainly for simpler forward compatibility with
libplacebo v4+.
Check that the linker features from Darwin ld64 for marking a symbol as
undefined (in the context of two-level namespace, it means that it can
be looked up in other namespaces) are usable. If they are not, the
static module bank is disabled since it depends on either static linkage
(which is obviously not affected by this option) or more generally the
ability to look up the static module bank symbol in a different linkage
unit/namespace.
In particular, they are currently not usable when enabling bitcode
through LDFLAGS+=" -fembed-bitcode" and compiling dynamically. On tvOS,
bitcode is mandatory, so supporting compiling with bitcode but without
the static module bank seems a rather good compromise given that it was
disabled anyway previously.
In static builds (the current shipping target for iOS and tvOS), the
static module bank stays enabled by the !HAVE_DYNAMIC_PLUGINS check.
Those frameworks only exist for MacOSX, so it was invalid to set them up
in the general case. Fortunately, it wasn't really used on iOS and tvOS
for the executables so it didn't have consequences.
On MacOSX, the targets needing this framework already link it so it is
not needed.
This is often used in pair with OLE API's like SysAllocString or VariantInit.
This is necessary in UAP/Winstore builds as it's not part of the default libs.
This makes it consistent with all the other uses of such defines in
the source code, which are tested for their existence rather than the
actual value.
When avcodec is found, it does not really add much value to check for
the avcodec header. avutil is required by it, so checking for that
is not needed either.
For avformat, avcodec is required, therefore checking for
avcodec and avutil headers is not needed there either.
Conditionally including those in avcommon_compat.h does not
seem needed at all, as it won't compile without these headers
anyway.
As per the Clang documentation, some sanitizers
only work with position independent executables,
so it is implied already by the sanitizer flag:
> Non-position-independent executables are not supported.
> Therefore, the fsanitize=thread flag will cause Clang
> to act as though the -fPIE flag had been supplied if
> compiling without -fPIC, and as though the -pie flag
> had been supplied if linking an executable.
https://clang.llvm.org/docs/ThreadSanitizer.html#limitations
This lifts the v1.7.0 dependency from the vulkan-specific check out into
the general libplacebo pkgconfig check, a change which is required for
the following refactor of vulkan/display.c into libplacebo/display.c.
A separate dependency for v0.5 is no longer needed, since it's very old
and no longer shipping anywhere (including debian stable). Therefore,
simplify the logic rather than recreating it exactly.
i'd guessed at what the right AVX2 instruction might be when i added
the new check, then forgot to later go back and do it properly
before it got merged.
Sort of revert 1d2b56c68b but it actually
finish the work done in ticket #9367 by removing the last recursive
makefile target in modules/.
It allows faster make (though not significant here) but most of all,
sharing the same variable definition scope in modules/ for all
makefiles.
In particular, this facilitate for future work implementing partial
linking at the module level, which actually needs the list of all
plugins being compiled.
The MMAL_CFLAGS / MMAL_LIBS will be used in the Makefile.am instead of
the plugin defined flags, since there are multiple plugins, and in
addition of a HAVE_MMAL conditional.
In addition, -L flags are LIBADD flags, and not LDFLAGS flags, so it's
actually put into MMAL_LIBS instead of defining a MMAL_LDFLAGS.
With autoconf 2.70, the following warnings are emitted:
configure.ac:56: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
configure.ac:56: the top level
The documentation[1] of autoconf now states:
> Prior to Autoconf 2.70, AC_PROG_LEX did not take any arguments, and
> its behavior was different from either of the above possibilities: it
> would search for a library that defines yywrap, and would set LEXLIB
> to that library if it finds one. However, if a library that defines
> this function could not be found, LEXLIB would be left empty and LEX
> would not be reset. This behavior was due to a bug, but several
> packages came to depend on it, so AC_PROG_LEX still does this if
> neither the yywrap nor the noyywrap option is given.
>
> Usage of AC_PROG_LEX without choosing one of the yywrap or noyywrap
> options is deprecated. It is usually better to use noyywrap and define
> the yywrap function yourself, as this almost always renders the LEXLIB
> unnecessary.
The behaviour of the argument on autoconf < 2.70 is to ignore the
argument, so there are no issues with adding the option.
[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Particular-Programs.html#Particular-Programs
This is a lot more accurate and wastes a lot less time than the Query approach.
The D3D11 Fence value is set when the GPU is done doing the previous
(rendering) commands. Then we can wait in the CPU for this event and return when
it's done. All decoder/filter commands seem to not have any impact so that's
really the signal we're looking for to tell the core we're done rendering.
This is only supported on newer mingw toolchains and only on Windows 10
Creators Update, which should cover pretty much all Win10 installed machines.
Better fixes#21600
All checks were nested which was really hard to read and modify
correctly. Instead use a state variable to track the detection status
and chain AS_IF condition for each test.
