[FFmpeg-devel] [PATCH] fix(configure): fix detection on windows arm64
Coia Prant
coiaprant at gmail.com
Wed May 14 11:36:11 EEST 2025
Or do we detect the MSYSTEM environment variable?
Martin Storsjö <martin at martin.st> 于 2025年5月14日周三 03:31写道:
> 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
>
>
More information about the ffmpeg-devel
mailing list