[PD-dev] qsort_r failure building puredata on Android?

[Miller Puckette]

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
> Pd-dev at lists.iem.at
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!VRG5jsBNd1QDG2j6c9cXeGSFkgCD-eJlDLN_Z2gSvGvmGSI4ejjljfzbPtYp$