[FFmpeg-devel] [PATCH] fix(configure): fix detection on windows arm64

[Martin Storsjö]

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 <coiaprant at 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