Or do we detect the MSYSTEM environment variable? Martin Storsjö <mar...@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 <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".
