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

Martin Storsjö martin at martin.st
Mon May 26 14:48:22 EEST 2025


On Sun, 25 May 2025, Martin Storsjö wrote:

> On Fri, 23 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
>> 
>> On x86 32-bit toolchain msys2 environment
>> `uname -m` returned `x86_64` instead of `i686` or `x86`
>> 
>> So check MSYSTEM_CARCH on windows (for arm64 and i686)
>> 
>> 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..ed30b6b 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 test "$MSYSTEM_CARCH" != ""; then
>> +    arch_default="$MSYSTEM_CARCH"
>> else
>>     arch_default=$(uname -m)
>> fi
>> -- 
>> 2.49.0.windows.1
>
> This approach seems reasonable to me.
>
> (On i686 vs x86_64, it hasn't been an issue, since they all map into "x86" 
> within ffmpeg, and configure then checks the bitness, but for arm64 it's 
> indeed an issue.)
>
> I can push the patch soon if nobody minds it.

Pushed now, with a rewritten commit message explaining the situation a bit 
more.

But it seems like I lost the reference to 
https://github.com/msys2/msys2-runtime/issues/171 while rewriting the 
text, sorry about that.

// Martin


More information about the ffmpeg-devel mailing list