- Oct 09, 2022
-
-
-
From testing, it seems that the qtsvg build retrieves zlib.h from $(PREFIX)/include/QtZlib/zlib.h. Its directory is specified with the -I flag. The $(PREFIX)/include directory is specified with the -isystem flag, which has lower priority than -I. So $(PREFIX)/include/zlib.h has the lowest priority, and the patch is not needed anymore. qtbase also includes plain <zlib.h>, but qtbase already has -I flags pointing directly to the vendored zlib directory in the source tree.
-
-
-
- Oct 08, 2022
-
-
Rémi Denis-Courmont authored
This was originally added to make builds with and without NEON on Android. I am not sure why this was at all needed as Android supports run-time detection using the normal Linux HWCAP mechanism, so a single build should have been feasible fairly easily. But anyhow, this is no longer used anywhere.
-
-
fix: #27388
-
-
-
-
-
-
-
- Oct 07, 2022
-
-
And rework the patching build calls.
-
-
No need to use a mv command for that. The package download command can download from one filename and output to another. Now we can use UNPACK_DIR
-
Rémi Denis-Courmont authored
Support for AArch64 was added in speexdsp 1.2.0~rc5, except on Windows for which we already have a patch.
-
Rémi Denis-Courmont authored
The HAVE_NEON flag is only ever defined on select platforms. That is to say first Android which had one build with and one without it. Later on, it was also added to iOS. It cannot be assumed that NEON is not there just because the flag is unspecified. This silently broke NEON support on Linux, and literally any other platform at the time this regression was introduced. Strictly speaking, we could keep checking the flag on Android or iOS on ARM or AArch64. But as of now, all four of those platforms always set HAVE_NEON, so this would not have any effect. We still forcefully disable NEON on Android-x86, which was the original purpose of this stanza. Regression from ef98e81f.
-
QT_STATICPLUGIN is meant for building a static Qt plugin [1], and not for testing if the used Qt is a static or shared build: That should be done with QT_STATIC. Since we are not building a static Qt plugin, use QT_STATIC. 1. https://doc.qt.io/qt-5/plugins-howto.html#creating-static-plugins
-
This is strictly identical to the previous situation since HAVE_NEON is set during bootstrapping on iOS only for armv7 targets anyway. The commit prepares the removal of the HAVE_NEON flag completely in later commits, which is redundant with armv7 check since we don't support non-neon-capable armv7 targets anymore.
-
* Added configurations and scripts for continuous integration. * Fixed various errors in the handling of tRNS, hIST and eXIf. * Implemented many stability improvements across all platforms. * Updated the internal documentation.
-
And don't depend on an outdated automake 1.11 version.
-
- Oct 06, 2022
-
-
fix: #27374
-
Steve Lhomme authored
This commit avoids an implicit cast from pthread_t * to unsigned long.
-
It should be there as we require gettext since d1d2759d.
-
Since VLC 3.0.x, VA-API no longer forcefully depends on libavcodec, even if it is not particularly useful without it. In fact, if libva is present, libavcodec absent, and the build system already gladly builds VA support minus the libavcodec plugin.
-
Original patch authored by Christoph Reiter
-
- Oct 05, 2022
-
-
See release notes: https://aomedia.googlesource.com/aom/+/refs/tags/v3.5.0
-
It should be faster and the license is the same type.
-
Rémi Denis-Courmont authored
This is the default, and has no actual effects. The FFmpeg configure script will check if NEON is supported *unless* given --disable-neon is passed. By comparison, the ARMv6 condition below is correct (at least in this respect) in forcefully disabling NEON.
-
Rémi Denis-Courmont authored
This was cargo-culted on Android and (desktop) macOS, and had no actual effects. The only uses of the flag in contribs are: - in main.mak, and only on iOS, thus no effects on AArch64, - in the FFmpeg package, explicitly only on AArch32, - in the speexdsp, effectively only on AArch32 (see previous commit). On AArch64, NEON is enabled by default. iOS, non-Android Linux and Windows builds have relied on this from the beginning. This patch is effectively a no-op. Fixes #27379.
-
Rémi Denis-Courmont authored
On AArch64, NEON is unconditionally disabled right above. This was only adding it a second time on all AArch64 targets other than iOS and Android, with no real effects. On non-ARM architectures, the flag is useless, and HAVE_NEON is meaningless so ignore it. On AArch32, HAVE_NEON is still abode by; this patch is a no-op.
-
In b8eb8c6d, this patch was manually touched up to make it apply on a newer version of CMake - the line counts mismatched slightly, but GNU patch 2.7.6 still happily managed to apply it. However patch 2.5.8 in macOS failed to apply the patch due to the mismatched numbers of lines. This makes the patch apply correctly with the version of patch on macOS too. This should fix issue #27381.
-
Steve Lhomme authored
We already have a UWP build for win64 that should be enough to test UWP builds.
-
Steve Lhomme authored
-
Steve Lhomme authored
To avoid confusion with what to contrib source contains.
-
Steve Lhomme authored
While "pthreads" here actually means mingw-w64.
-
Steve Lhomme authored
-
Steve Lhomme authored
-