On Mon, 12 May 2025, Coia Prant wrote:
On Windows Arm64
`uname -m` returned `x86_64` instead of `aarch64`
Link: https://github.com/msys2/msys2-runtime/issues/171
But `uname -s` contains `ARM64` suffix
So check suffix on windows arm64 (for clangarm64)
This problem also in VideoLAN/x264
Link: https://code.videolan.org/videolan/x264/-/merge_requests/177
Signed-off-by: Coia Prant <coiapr...@gmail.com>
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 2e69b3c..d8c1e09 100755
--- a/configure
+++ b/configure
@@ -4157,6 +4157,8 @@ if test "$target_os_default" = aix; then
arch_default=$(uname -p)
strip_default="strip -X32_64"
nm_default="nm -g -X32_64"
+elif [[ "$target_os_default" == "mingw"*"arm64" ]] || [[ "$target_os_default" ==
"msys"*"arm64" ]]; then
+ arch_default="aarch64"
else
I don't think we should be detecting this for the msys*arm64 cases here.
If we're in the msys environment, as opposed to the mingw ones, then the
x86_64 that "uname -m" returns really is correct (even if running emulated
on aarch64, the msys environment itself is x86_64, so that's the target
architecture of the compilation).
For the mingw*arm64 case, I haven't thought about all the potential
consequences of the patch; it may be acceptable. But the script is a
strict POSIX sh script, it can't use bash constructs (which is what
Michael observed in testing the patch).
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
