Problem description

I was going to put this in #21835 , alongside all the other changes for packages that fail to build if you use scripts/run-docker.sh ./build-package.sh xxx yyy in some combination, but the PR is getting too big and might be causing an intermittent CI error because of having too many packages changed in it, so I need to start separating every change out into its own PR, and later I will try to break up the other things in that PR into smaller pieces.

If predict's source code detects the presence of the alsa-lib package in the prefix, it activates a "generic Linux" block and deactivates a Termux-aware block written by the upstream developer.

Since the upstream code's "generic Linux" block contains snd_pcm_open() which is noted in a comment in the Termux alsa-lib package as non-functional on Android, I am pretty sure the correct change is this, to force ignoring alsa-lib and keep the play-audio codepath written by the upstream developer activated. It does seem odd to me that the "predict-2.3.1-termux.tar.gz" archive released by the upstream developer would contain a vestigial generic Linux codepath, though, so if there were an official issue tracker for the upstream project, I would report it there so there could be a chance of this patch I made no longer being required eventually. I haven't been able to find one.

What steps will reproduce the bug?

scripts/run-docker.sh ./build-package.sh alsa-lib predict

ld.lld: error: undefined symbol: snd_pcm_open

What is the expected behavior?

Termux-aware application predict should always force its intended play-audio-based codepath and ignore the alsa-lib package at least until the alsa-lib package gets its snd_pcm_open() backend patched into something else, since the alsa-lib package in Termux appears to be a stub for building software that doesn't actually call snd_pcm_open() since it says that snd_pcm_open() doesn't usually work on Android.

System information

N/A