/var/tmp/deps/src/sqlite-autoconf/sqlite3.c:38937:8: error:

You'll need to tell us precisely which version you're working from. Without that, the line number is useless.

$ grep -c 'zErr =' sqlite3.c
117

Edit: i now see the version being passed along in the compilation flags, but (A) that is unreliable and (B) don't do that - the source code includes its version number. We need the hash of the version you're using.

I just realized I was not building the latest version of SQLite at all, sorry.

It still happens on 3.45.1 however:

libtool: compile:  armv7a-linux-androideabi21-clang -DPACKAGE_NAME=\"sqlite\" -DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.45.1\" "-DPACKAGE_STRING=\"sqlite 3.45.1\"" -DPACKAGE_BUGREPORT=\"http://www.sqlite.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"sqlite\" -DVERSION=\"3.45.1\" -D_FILE_OFFSET_BITS=64 -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_POSIX_FALLOCATE=1 -DHAVE_ZLIB_H=1 -I. -I/var/tmp/deps/src/sqlite-autoconf -D_REENTRANT=1 -DSQLITE_THREADSAFE=1 -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_HAVE_ZLIB -fPIC -mthumb -MT sqlite3.lo -MD -MP -MF .deps/sqlite3.Tpo -c /var/tmp/deps/src/sqlite-autoconf/sqlite3.c -o sqlite3.o
/var/tmp/deps/src/sqlite-autoconf/sqlite3.c:39267:8: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion]
  zErr =
       ^
1 error generated.

This is sqlite-autoconf-3450100.tar.gz downloaded from the website just five minutes ago.

The code in question in the source repo seems to be this: https://github.com/sqlite/sqlite/blob/6161cdd446eec170f7c0edf58d0d72a2cd3c5f85/src/os_unix.c#L1287-L1302

(B) don't do that - the source code includes its version number

The compile flags are not my choice, I am merely using the included autoconf script :)

The code in question in the source repo seems to be this: ...

As a quick workaround, can you please try a local patch like (untested):

#if (defined(STRERROR_R_CHAR_P) || defined(__USE_GNU)) \
  && (!defined(ANDROID) && !defined(__ANDROID__))
...

And let us know if that works for you?

Apparently the existing #if check is matching for Android but shouldn't be.

That compiles fine.

What also works is removing the || defined(__USE_GNU) part.

That compiles fine.

Does it run, though? My reading of your reported warning is that strerror_p() is not defined on your target system, so the resulting library/app will fail to load due to an unresolved symbol error.

My proposed change would look something like:

Index: src/os_unix.c
==================================================================
--- src/os_unix.c
+++ src/os_unix.c
@@ -1294,14 +1294,16 @@
   ** If the code incorrectly assumes that it is the POSIX version that is
   ** available, the error message will often be an empty string. Not a
   ** huge problem. Incorrectly concluding that the GNU version is available
   ** could lead to a segfault though.
   */
-#if defined(STRERROR_R_CHAR_P) || defined(__USE_GNU)
+# if !defined(ANDROID) && !defined(__ANDROID__)
+#  if defined(STRERROR_R_CHAR_P) || defined(__USE_GNU)
   zErr =
-# endif
+#  endif
   strerror_r(iErrno, aErr, sizeof(aErr)-1);
+# endif
 
 #elif SQLITE_THREADSAFE
   /* This is a threadsafe build, but strerror_r() is not available. */
   zErr = "";
 #else

Yes, it does run too.

As I quoted from the system headers in the first post strerror_r exists, it just doesn't return a char pointer (in these circumstances).

As I quoted from the system headers in the first post strerror_r exists, it just doesn't return a char pointer (in these circumstances).

Indeed, you did. i got distracted the other details and didn't reach that point! We'll get this patched with the first of the upthread approaches by tomorrow at the latest. Thank you for the report and confirmation of the patch.

From https://linux.die.net/man/3/strerror_r:

int strerror_r(int errnum, char *buf, size_t buflen);
            /* XSI-compliant */

char *strerror_r(int errnum, char *buf, size_t buflen);
            /* GNU-specific */

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

The XSI-compliant version of strerror_r() is provided if:
(_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
Otherwise, the GNU-specific version is provided. 

The strerror_r() function is similar to strerror(), but is thread safe.

If no feature test macros are explicitly defined, then (since glibc 2.4) _POSIX_SOURCE is defined by default with the value 200112L, so that the XSI-compliant version of strerror_r() is provided by default.

The XSI-compliant strerror_r() is preferred for portable applications.

Sorry, I commented but I see it's patched, just not released.

Thanks for the fix! This warning turned into an error recently.

check-in f18b2524da6bbbcf will appear in the next release.