Add a test script that verifies all plugins listed in vlc_modules_list
exist at their specified paths. This catches issues like incorrect
library extensions on different platforms.
Move the vlc_modules_list generation logic to a shared modulelist.mk file
that can be included by both modules/Makefile.am and modules/gui/qt/Makefile.am.
Now each directory generates its own vlc_modules_list using LTLIBRARIES,
and the parent concatenates lists from SUBDIRS.
Change vlc_modules_list format from just plugin names to name:path pairs.
This allows plugins built in SUBDIRS (like the Qt plugin) to specify
their actual location, enabling copy_plugins.sh to find them.
New format: plugin_name: relative/path/to/plugin.dylib
The path is relative to the top build directory as it also inject
$(subdir) in the path from Makefile.am.
We want to fetch the vlc_modules_list from subdirectories but they must
have already processed their files so that we can include our.
Fix this by reordering SUBDIRS so that "." is processed last instead of
first. This way SUBDIRS (like gui/qt) generate their vlc_modules_list
before the parent directory tries to concatenate them.
This commit signal the mostlyclean and other dependant targets that it
should clean the targets generated by cargo.
We use a separate target name and add the dependency to
mostlyclean-local so that we can still extend the known automake target.
We also don't use CLEANFILES so that dependencies files are also removed
when using `make mostlyclean-local-rust` to avoid a corrupted tree where
the dependencies would not be removed but the target files they
reference would not exist anymore.
During installation, no dependencies existed between the targets being
installed and the targets being relinked against the installed version,
which made the following race condition:
../doltlibtool --mode=install /usr/bin/install -c libvlc_pipewire.la libvlc_pulse.la libvlc_vdpau.la libvlc_xcb_events.la '/builds/videolan/vlc/vlc-4.0.0-dev/_inst/lib/vlc'
libtool: install: (cd /builds/videolan/vlc/vlc-4.0.0-dev/_build/sub/modules; /bin/bash "/builds/videolan/vlc/vlc-4.0.0-dev/_build/sub/modules/../libtool" --silent --tag CC --mode=relink gcc -g -O2 -pthread -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith -Wvolatile-register-var -Wformat -Wformat-security -Wduplicated-branches -Wduplicated-cond -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes -Werror-implicit-function-declaration -Winit-self -Wlogical-op -Wshadow=local -Wmultistatement-macros -pipe -Werror=missing-field-initializers -Werror=format -Werror=incompatible-pointer-types -Werror=restrict -Werror=int-conversion -Werror=implicit-int -Werror=return-mismatch -Werror=declaration-missing-parameter-type -fvisibility=hidden -fno-math-errno -funsafe-math-optimizations -fno-rounding-math -fno-signaling-nans -fcx-limited-range -funroll-loops -fstack-protector-strong -avoid-version -module -export-symbols-regex "^vlc_entry" -shrext .so -no-undefined ../compat/libcompat.la ../src/libvlccore.la -Wl,-z,defs -o libvdpau_instance_plugin.la -rpath /builds/videolan/vlc/vlc-4.0.0-dev/_inst/lib/vlc/plugins/vdpau hw/vdpau/libvdpau_instance_plugin_la-device.lo libvlc_vdpau.la -lSM -lICE -lX11 -lanl )
libtool: install: /usr/bin/install -c .libs/libvlc_vdpau.so.0.0.0 /builds/videolan/vlc/vlc-4.0.0-dev/_inst/lib/vlc/libvlc_vdpau.so.0.0.0
/usr/bin/ld: cannot find -lvlc_vdpau: No such file or directory
libtool: install: (cd /builds/videolan/vlc/vlc-4.0.0-dev/_inst/lib/vlc && { ln -s -f libvlc_vdpau.so.0.0.0 libvlc_vdpau.so.0 || { rm -f libvlc_vdpau.so.0 && ln -s libvlc_vdpau.so.0.0.0 libvlc_vdpau.so.0; }; })
collect2: error: ld returned 1 exit status
libtool: install: (cd /builds/videolan/vlc/vlc-4.0.0-dev/_inst/lib/vlc && { ln -s -f libvlc_vdpau.so.0.0.0 libvlc_vdpau.so || { rm -f libvlc_vdpau.so && ln -s libvlc_vdpau.so.0.0.0 libvlc_vdpau.so; }; })
----------------------------------------------------------------------
libtool: error: error: relink 'libvdpau_instance_plugin.la' with the above command before installing it
libtool: install: /usr/bin/install -c .libs/libvlc_vdpau.lai /builds/videolan/vlc/vlc-4.0.0-dev/_inst/lib/vlc/libvlc_vdpau.la
make[6]: *** [Makefile:15527: install-vdpauLTLIBRARIES] Error 1
Here, with the thread number, we have:
- (1) doltlibtool installing the pkglibs (install-exec-am).
- (2) in parallel, libtool relinking the vdpau instance plugin.
- (1) libtool starts to be called for "relinking" (which is only
installing there) with version 0.0.0.
- (2) libtool tried to run the linker but it failed because
libvlc_vdpau.so doesn't exist yet on the target prefix.
- (1) libtool .0.0.0 links to the major version shortcut .0 for
libvlc_vdpau.
- (1) libtool .0.0.0 links to the unversioned shortcut for
libvlc_vdpau.
So the pkglibs were not installed before installing the plugins linking
them and it was racy whether automake succeeded in installing vlc_vdpau
before or not. This could apply to any pkglib being used from plugins.
This patch ensure the pkglibs are installed before relinking the plugins
for vpdau, same must be done for each other pkglib usage location.
Note that install-vdpauLTLIBRARIES itself will install each target from
vdpau_LTLIBRARIES serially in the order they are defined, so there would
be no race inside the same LTLIBRARIES variables, but the different
LTLIBRARIES variables are processed in parallel themselves.
Fixes#28374
The parameter is forwarded to Cargo to handle re-compiling the standard
library. This is required when targetting tier 3 targets like
aarch64-apple-tvos, where the standard library is not shipped with the
compiler binaries.
Initial design used --with-cargo-build-std which only triggered rebuild
of the std in cargo, but this new design for the option allows more
specification about what needs to be built, can be extended to support
--extern crate later when the std makes it easy to do so, and I felt it
was clearer to read the option, though finding it is a bit less easy.
Example:
--with-rust-std=build-std=std,panic_abort
Ensure that !HAVE_DYNAMIC_PLUGINS is correctly forwarded to Cargo so
that modules that are built statically are really built with the static
plugin API conventions, with suffixed `vlc_entry*` functions names.
This really enables and implement the static flavour for the Rust
plugins.
Make the script work like Makefile.am files, by allowing to specify
where libtool is meant to be found. Using the same libtool as autoconf
will ensure we use the correct wrapper or alternative implementation as
specified by autoconf.
The autotools suite (automake, libtool, ...) does not support Rust
neither Cargo (Rust package manager and build system) so we need to have
a custom system for using them. We do this by having "hacky" script that
does the build with cargo and output an .a archive in the .libs
directory. And with this and another cargo command we create the .la
with the right information so that the build system can continue as
usual.
The build system is generating plugins and installing them at the PREFIX
location, but it is also often used by extra build scripts using it.
Those build scripts were trying to list the plugins by listing the files
in the PREFIX folder, but it was often inadequately using stall
plugins.
By generating an up-to-date list of plugins by the build system, we can
check when the plugin list have changed and which plugins should be
copied to the final application.
Down the line, we probably should not have one directory per ISA
extension. This replicates the model from the hw/*/ directory.
isa/ seems better than arch/ because:
- "Instruction Set Architecture" is more specific than "Architecture",
- it saves one character,
- no modules/ subdirectory starts with I yet (so this will not break
auto-completion habits).
This also moves non-NEON-specific files to isa/arm/.
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.
This is based on the GSoC project of Jai Luthra which final code can be
found here https://code.videolan.org/gsoc2019/darkapex/vlc/commits/nvdec_merge
The added patches on top of this proposal (cleaning, fixing, more codecs) can
be found here https://code.videolan.org/robUx4/vlc/tree/nvdec/10
By default we use Bob deinterlacing if the source is interlaced.
Do not use the VP9 decoder if the profile is unknown, it may need 10 bits
support and the hardware may not support it. This is the same way we support
VP9 in DXVA.
The decoder currently has a lower priority than libavcodec.
Co-authored-by: Jai Luthra <me@jailuthra.in>
Co-authored-by: Steve Lhomme <robux4@videolabs.io>
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
The QApplication constructor exits the entire process if it cannot find
a working Qt back-end. This is unacceptable within VLC, as we expect to
fallback to another interface plugin in such circumstances.
Qt 4.x selected its back-end at build time. VLC would try to connect to
the same back-end system (in practice: X11) to second-guess
QApplication, and preempt the initialization failure.
Qt 5.x selects its back-end at run time depending on installed back-end
plugins and running windowing system(s). There are no reasonable and
reliable ways to second-guess Qt anymore.
This commit introduces a dummy executable program that simply tries to
instantiate a QApplication. If it succeeds, it returns 0. Otherwise, it
returns an error. This allows its parent process to safely check if Qt
is available at run-time.
This avoids having to enable it explicitly in configure, while also not
installing it by default outside build trees. In the unlikely event
that you actually want to install the plugin, you can still do so but
manually (e.g. libtool install mode).
These changes introduces a new module type named stream_extractor. The
added documentation should explain when such module should be used,
but in short it allows for extraction of data within a stream,
effectively resulting in a new stream that refers to the extracted
data.
Interaction with the stream-extractor shall never happen directly,
instead the module-backend is written in a way so that it exposes a
stream_t to the public.
[ access ] -> [ stream_t ] -> [ stream consumer ]
'- [ stream extractor ]
Future changes are necessary in order to make modules of this type
usable in practice, but has been split into individual commits so that
the changes are easier to follow.
Signed-off-by: Thomas Guillem <thomas@gllm.fr>
Deactivated by default since secret is not encrypted.
To use it (for test purpose only):
./vlc --keystore=plaintext --keystore-plaintext-file=<my_file> <url>
Alexandre Janniaux
Loïc
Steve Lhomme
Rémi Denis-Courmont
Jai Luthra
Steve Lhomme
Victorien Le Couviour--Tuffet
Filip Roséen
Thomas Guillem
Jean-Baptiste Kempf