It won't be thread-safe, which I believe you need to worry about in Android which is shot through with Java crappiness. I _think_ you can make MICROSOFT_STUPID_SORT work in a hreaded environment by declaring stupid_zkeyinfo as static per-thread.
But I wonder how on earth people are supposed to do this without wierd workarounds like that.... cheers Miller On Tue, Oct 27, 2020 at 11:49:29AM -0400, Andi McClure wrote: > I am building puredata via libpd on Android (a fork off 0.51/d5766fd0). I > am doing this by loading the libpd CMakeLists.txt from my own CMakeLists > invoked from gradle and then linking libpd in my Android app. > > When it gets to the step of building libpd.so, it prints: > > libpd/CMakeFiles/libpd.dir/pure-data/src/x_text.c.o: In function > `text_define_sort': > > /path/to/repo/deps/libpd/pure-data/src/x_text.c:552: undefined reference > to `qsort_r' > > 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://urldefense.com/v3/__https://android.googlesource.com/platform/bionic/*/master/libc/libc.map.txt__;Kw!!Mih3wA!VRG5jsBNd1QDG2j6c9cXeGSFkgCD-eJlDLN_Z2gSvGvmGSI4ejjljUGMEDph$ > > 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.) > _______________________________________________ > Pd-dev mailing list > [email protected] > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!VRG5jsBNd1QDG2j6c9cXeGSFkgCD-eJlDLN_Z2gSvGvmGSI4ejjljfzbPtYp$ > _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
