Repository navigation
Conversation
ylatuya
force-pushed
the
fix/windows-decoder-patches
branch
2 times, most recently
from
November 5, 2026 15:30
a5e6332 to
723aade
Compare
ylatuya
changed the title
ylatuya
force-pushed
the
fix/windows-decoder-patches
branch
from
November 5, 2026 15:37
723aade to
49d6ee1
Compare
ylatuya
force-pushed
the
fix/windows-decoder-patches
branch
from
November 5, 2026 15:49
49d6ee1 to
5caf872
Compare
The JM ARM64 patch declared 8/10 lines while its body has 7/9, so git apply rejected it on Windows. GNU patch tolerated the mismatch on the other platforms, which is why JM was silently disabled only on Windows. The MPEG-4 AAC Windows headers patch declared 11/11 lines while its body has 14/12, so it never applied. It also guarded sys/wait.h only with WIN32, which MinGW does not define (it defines _WIN32), so the include would still fail after applying the patch. Fix both hunk headers, guard the POSIX headers with both WIN32 and _WIN32, and stop excluding ldecod and mp4audec from the Windows decoder verification. Also mark *.patch as text eol=lf. Git on Windows checked the patches out with CRLF, which makes git apply report them as corrupt before it even looks at the headers. Run the git apply fallback from the target directory: --directory with an absolute path is rejected by git apply on Windows, so every MPEG-4 AAC patch failed there.
ylatuya
force-pushed
the
fix/windows-decoder-patches
branch
from
November 5, 2026 15:58
5caf872 to
3672201
Compare
rsanchez87
self-requested a review
November 6, 2026 08:03
rsanchez87
approved these changes
Nov 6, 2026
Contributor
|
related with this PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #419 discussion_r4464811839, based directly on
master.Several issues prevented the Windows reference builds:
subprojects/packagefiles/jm/0001-Fix-ARM64-build-disable-SSE-on-ARM-architectures.patchdeclared 8/10 lines but has 7/9, sogit applyrejected it. GNU patch tolerated the mismatch on Linux/macOS, which is why JM was silently disabled only on Windows.build/patches/mpeg4aac-windows-headers.patchdeclared 11/11 lines but has 14/12, so it never applied. It also guardedsys/wait.honly withWIN32, which MinGW does not define (it defines_WIN32), so the include still failed after applying it.*.patchfiles out with CRLF line endings, which makesgit applyreport the patches as corrupt before it reads the headers.download_deps.pyrangit apply --directory <absolute path>, whichgit applyrejects on Windows, so every MPEG-4 AAC patch failed there.This fixes both hunk headers, guards the POSIX headers with
WIN32and_WIN32, marks*.patchastext eol=lf, runs thegit applyfallback from the target directory, and removes the Windows CI exclusions forldecodandmp4audec. Verify decoders now checks the full set on every platform.