Regression from d9c9482b25.
This fixes linking on macOS with static Qt from contribs:
Undefined symbols for architecture x86_64:
"_BZ2_bzDecompress", referenced from:
_ft_bzip2_file_fill_output in libfreetype.a(ftbzip2.c.o)
"_BZ2_bzDecompressEnd", referenced from:
_ft_bzip2_stream_io in libfreetype.a(ftbzip2.c.o)
_ft_bzip2_stream_close in libfreetype.a(ftbzip2.c.o)
"_BZ2_bzDecompressInit", referenced from:
_FT_Stream_OpenBzip2 in libfreetype.a(ftbzip2.c.o)
_ft_bzip2_stream_io in libfreetype.a(ftbzip2.c.o)
ld: symbol(s) not found for architecture x86_64
It is built, but not installed. This causes problems on macOS when
linking our libqt_plugin:
clang: error: no such file or directory: '/vlc/contrib/x86_64-apple-darwin19/lib/libQt5PrintSupport.a'
Since we don't use any of the printer related functionality, disable it
altogether.
This reverts commit cee6cee6aa.
Unfortunately, removing create_libtool from CONFIG in the toolchain file
gets overridden when it is added to CONFIG again in qt_module.prf.
Qt itself adds it to CONFIG for "!lib_bundle:unix", indeed in the
Windows contrib archive, libQt5Bootstrap.la can be spotted (as this is
for the native build only). Also, when building for Debian, all Qt
modules will install .la files, like libQt5Core.la.
As qt_module.prf is the only place in the whole of Qt where this is
added to CONFIG, it should be sufficient to patch it here.
This pupnp release address some win32 issues reported after we bumped to
1.14.
Removed patches:
- 0001-ThreadPool-[...].patch -> Fixed upstream by d4cfec4674c6877bad350
- win32-remove-wro[...].patch -> Fixed upstream by d86f4159e13d00a9eb59a
This release also fixes an XML descriptor parsing error:
<https://github.com/pupnp/pupnp/issues/412>
The gnulib packaged doesn't seem to match the source (wint_t detection
differences). We can just force EXTRA_PROGRAMS to avoid building the
executables.
The strverscmp() patch doesn't seem necessary anymore.
According to #24678 it should work with Clang 5 and above. Not sure there are
iOS/XCode toolchain still available that can target iOS 9 with an older Clang.
The iOS armv7 target continues to build assembler as before.
Rather than relying on it being installed somewhere on wine we can use our own
and control which version is used.
It's always added to the windows builds even though it may not be used in the
end. But the package is not big and doesn't require any building.
It requires dotnet 4.0 being installed in Wine.
While WIX is open source, the wix 3.5 we are using cannot realistically be
built in our contribs as it's hardcoded to build with VS 2008. Even the most
recent builds of WIX still don't build in Linux. We already use a prebuilt
version in Docker images, except it's a .msi file that is installed via wine.
This fixes building with llvm-mingw for i686 (which uses dwarf
for unwinding on i686) after updating to Rust 1.65.0 in
cb4464ddf0.
The problematic patch was needed for fixing build breaks with
mingw toolchains that use SjLj exception handling (which is what
is used in VLC's current CI builds for mingw/i686) - which is
https://github.com/rust-lang/rust/issues/79609.
Rust's stdlib contains references to the _Unwind_Resume symbol
(which is what the symbol is called in dwarf unwinding cases),
but it's not meant to actually be called (since rav1e is built
with "-C panic=abort"). If the mingw toolchain itself uses dwarf
(or SEH) unwinding, then the _Unwind_Resume symbol is provided
from that unwinder. But in the case of SjLj toolchains,
the toolchain only provides a symbol named __Unwind_SjLj_Resume.
The patch provided a dummy _Unwind_Resume symbol as part of the
rav1e build, which fixed the undefined references with SjLj toolchains.
However, since updating to Rust 1.65.0, other object files in
the Rust stdlib seems to pull in more unwinding symbols (there
are undefined references to e.g. _Unwind_GetRegionStart). These
other symbols are named the same both in dwarf, SjLj and SEH
toolchains. In the case of SjLj toolchains, they ended up pulled
in from libunwind/libgcc, but in the case of dwarf or SEH toolchains,
the locally defined _Unwind_Resume caused a conflict with the real
one which ended up included from libunwind/libgcc.
To avoid the issue, provide all referenced symbols as similar stubs;
this makes sure that the build doesn't end up pulling in anything
unwinding related from libunwind/libgcc, either in SjLj or dwarf
toolchains.
Contribs used to be build in the source tree. Autotools sometimes complain when
you configure outside of tree if you had configured inside the tree before.
We just need to remove the file it uses for detection of older builds.
Fixes#27521
I got a Linux x86-64 build complaining it was not built with PIC.
/usr/bin/ld: /root/build/contrib/x86_64-linux-gnu/lib/libfluidsynth.a(fluid_sys.c.o): warning: relocation against `in6addr_any@@GLIBC_2.2.5' in read-only section `.text'
/usr/bin/ld: /root/build/contrib/x86_64-linux-gnu/lib/libfluidsynth.a(fluid_sys.c.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
I got a Linux x86-64 build complaining it was not built with PIC.
/usr/bin/ld: /root/build/contrib/x86_64-linux-gnu/lib/libfreetype.a(truetype.c.o): warning: relocation against `TT_RunIns' in read-only section `.text'
/usr/bin/ld: /root/build/contrib/x86_64-linux-gnu/lib/libfreetype.a(truetype.c.o): relocation R_X86_64_PC32 against symbol `TT_RunIns' can not be used when making a shared object; recompile with -fPIC
CFLAGS/CPPFLAGS are ignored, all the variables from HOSTVARS and HOSTVARS_PIC
are ignored. The values need to be set in the relevant variables.
/usr/bin/ld: /root/build/contrib/x86_64-linux-gnu/lib/liblua5.4.a(liolib.o): warning: relocation against `stdin@@GLIBC_2.2.5' in read-only section `.text'
/usr/bin/ld: /root/build/contrib/x86_64-linux-gnu/lib/liblua5.4.a(lauxlib.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
This does essentially the same as upstream commit
c19cb93d492e45141bfef9b926dfeba36003261c but by patching
the resulting .pc file, as autoreconf'ing gnutls leads to issues.
This reverts commit 8c7ce5361f.
In debug mode, Qt's bundled ANGLE throws an assertion on startup. This
prevents the nightlies from starting.
Fixes#27476