We've been running into the same issue with our armv7 builds (arm64 builds were fine). With this patch the DNN_COMPUTE_ACTIVATION_IMPL and DNN_COMPUTE_CONV2D_IMPL problems are gone, but DNN_COMPUTE_LINEAR_IMPL is still not found, so I suppose there is still a difference in the CMake build somewhere regarding different ARM architectures (we're configuring both architectures with the same features, just to see if the ML features are even feasible on armv7).

I personally deactivated the use of the ML-based features for armv7, as it seems to require neon to run. armv7-only devices are pretty rare anyway, too bad for them :)

Yeah, in the meantime I have also resorted to just disabling this option for ARMv7 on Android. It would be nice CMake outright refused to build this configuration if it ends up in linking errors. (just to be clear, I don't expect that to be adressed in this PR, but if Opus devs see this, maybe that would be some inspiration to make the CMake script a bit more sturdy).

I personally deactivated the use of the ML-based features for armv7, as it seems to require neon to run. armv7-only devices are pretty rare anyway, too bad for them :)

Technically, the code can run without Neon and can use RTCD to turn Neon on-off dynamically. Practically, I don't think there's any non-Neon ARM chips that will run the DNN C code in real-time. Even 32-bit Neon chips will likely struggle. That being said, I think there are ARMv8 chips running 32-bit binaries and those should be able to run the DNN code with Neon. And those should be possible to detect at run-time to avoid running the DNN code on CPUs that are too slow.