I asked around about this, and was told a few things:

* Sometimes this kind of Android error magically goes away if you fiddle with compileSdkVersion in gradle.

* There is a list in this git repo:

   https://android.googlesource.com/platform/bionic/+/master/libc/libc.map.txt

   Of which libc symbols wind up in which binary in Android. However, in current Android master, qsort_r is not in this list at all. Only qsort.

* qsort_r is not a standard C function, it is a GNU thing, so it's possible Android really just doesn't have it. If Android really doesn't provide quicksort, it *might* be possible to fake qsort_r by adding a single C++ file which wraps std::sort (this was added in C++03 so Android *probably* has it), which doesn't have standard C qsort's reentrancy problem.

I found I was able to make it compile with the following patch:

diff --git a/src/x_text.c b/src/x_text.c

index 44bf9521..18f3d9de 100644

--- a/src/x_text.c

+++ b/src/x_text.c

@@ -474,9 +474,9 @@ equal:

 found in msvcrt (which indeed it isn't in).  Rather than waste more time

 on this, just call qsort if we're Microsoft and single-instance.  I hope nobody

 will try to compile multi-instance Pd for 32-bit windows, but if they

 do, they might run into my qsort_s problem again. */

-#if defined(_WIN32) && !defined(PDINSTANCE)

+#if (defined(_WIN32) || defined(__ANDROID__)) && !defined(PDINSTANCE)

 #define MICROSOFT_STUPID_SORT

 static void *stupid_zkeyinfo;

 static int stupid_sortcompare(const void *z1, const void *z2) {

     return (text_sortcompare(z1, z2, stupid_zkeyinfo)); }

So although I'm not exactly sure what x_text.c is doing here, I am unblocked, I can proceed with my project as long as I don't need multi-instance. But, I'd like to know, is this a known problem? I find many references to people building PureData on Android but no one seems to have hit this issue. If there is a known working configuration for PureData on Android, what git revision of PureData was it building and what NDK compileSdkVersion? Alternately, is it possible the problem is not with my configuration, but with the libpd CMakeLists, and this problem would go away if I added the right #define or -l link argument?

And if this is a new problem: Would a patch to address this be welcome, and what approach would be preferred? Should I just submit a patch triggering MICROSOFT_STUPID_SORT when __ANDROID__ is present?

(I understand libpd is a different project from puredata and apologize if this is the wrong place to ask given I'm building libpd. However this seems (?) like a problem in the pure-data part of the code.)