Open barracuda156 opened 7 months ago
Like your other reports. You're mixing a 18 years old as
command from an ancient Xcode version with a recently compiled gcc
. You should use a consistent toolchain, either by sticking to Xcode for everything, or at least by using gcc
with the GNU binutils (and a version from the same era).
This is not a bug in aom
.
It is a bug, because the configure check does not do what it is designed to do. It does not work correctly.
I have provided you an example of configure of libopus
which detects a lack of AVX successfully (on the same system): https://github.com/jedisct1/libsodium/issues/1350#issuecomment-1924177677
There is no problem with toolchain. In fact using Apple Unix tools is the recommended method by GCC upstream for building modern GCC, for example, on 10.5+.
UPD. The issue is with libyuv
code in fact, aom
just uses it.
UPD2. No, not only libyuv
, aom
own code too, for example aom_dsp
fails likewise.
Worse is that even if one builds something with some swapping of an external assembler with these instructions enabled, the resulting binary will be broken, since the CPU does not support those (this is CoreDuo, it does not have AVX).
Compiling different implementations is expected. All these tools detect CPU capabilities at runtime (see x86_simd_caps()
for example).
Tried to build
aom
on i386 (Core Duo) with GCC. Build misdetects AVX as supported and that breaks it:Configure checks for flags support, but that is not sufficient; compiler may support flags, but assembler may not support instruction set.