[PATCH] strerror_r-posix: port even better to Android

* lib/strerror_r.c: Use STRERROR_R_CHAR_P to decide whether the system strerror_r returns char *, and HAVE_DECL_STRERROR_R to decide whether it either does that or returns an integer. In the former case, use the system strerror_r even on platforms like Android API level 23 that don’t have __xpg_st

Re: #include on Android clang causes an error

i thought you might want the full log so here it is Running container 'termux-package-builder' from image 'termux/package-builder'... Creating new container... 5372f92bcc6a0cd8b72ad5a6642f0f686157453267663d595f632e008f1fd804 gpg: key 6700B77E6D8D0AE7: 4 signatures not checked due to missing keys g

Re: #include on Android clang causes an error

the strerror_r() warnings are still there, but this fixed the free() warning On Wed, Sep 8, 2021 at 5:56 PM Paul Eggert wrote: > > Thank you for reporting the additional problems with 'free' and with > 'strerror_r'. I have theories as to why these problems occur, and have > installed Gnulib patch

[PATCH 1/2] string, wchar: port rpl_free decl to Android

* lib/string.in.h, lib/wchar.in.h: (free): When replacing it, declare the unreplaced version too. Problem reported by Lucy Phipps in: https://lists.gnu.org/r/bug-gnulib/2021-09/msg00026.html --- ChangeLog | 8 lib/string.in.h | 1 + lib/wchar.in.h | 1 + 3 files changed, 10 inserti

[PATCH 2/2] strerror_r-posix: port better to Android

* m4/strerror_r.m4 (gl_FUNC_STRERROR_R): Move requirement of gl_USE_SYSTEM_EXTENSIONS from here ... (gl_FUNC_STRERROR_R_WORKS): ... to here, which is the macro that actually needs it. This avoids a bug where 'configure' tests whether strerror_r has the POSIX API before enabling GNU extensions. On

Re: [PATCH] string, wchar: avoid some namespace pollution

Oops, apologies, Paul. Your patch _does_ look correct. (I should have read the entire patch, not just the ChangeLog entry.) Bruno

Re: [PATCH] stack-direction: Add support for loongarch CPU

> -邮件原件- > 发件人: Bruno Haible > 发送时间: 2021年9月4日 21:17 > 收件人: bug-gnulib@gnu.org > 抄送: Sun Haiyong > 主题: Re: [PATCH] stack-direction: Add support for loongarch CPU > > Hi, > > Sun Haiyong wrote: > > * m4/stack-direction.m4 (SV_STACK_DIRECTION): When the CPU is > loongarch, > > set "sv_cv_

Re: [PATCH] string, wchar: avoid some namespace pollution

Hi Paul, > * lib/string.in.h, lib/wchar.in.h: > (free): Declare by hand instead of including stdlib.h. This does not look right to me. There are two cases: (A) REPLACE_FREE is 0. Then it is OK to declare it by hand, because gnulib uses the system's free() function. (B) REPLACE_FREE is 1. (T

Re: [PATCH] declare free() in lib/free.c

Hi, > @@ -27,9 +27,11 @@ > > # include > > +# undef free > +void free (void *); > + > void > rpl_free (void *p) > -# undef free > { > # if defined __GNUC__ && !defined __clang__ >/* An invalid GCC optimization > > Moving the '#undef' line up-front is generally not right: it makes it

[PATCH] declare free() in lib/free.c

avoids an implicit declaration warning --- lib/free.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/free.c b/lib/free.c index 780f03dd1..804640c2e 100644 --- a/lib/free.c +++ b/lib/free.c @@ -27,9 +27,11 @@ # include +# undef free +void free (void *); + void rpl_f

Re: #include on Android clang causes an error

this works, but there's an additional warning now: /home/builder/.termux-build/gzip/src/lib/free.c:48:3: warning: implicit declaration of function 'free' is invalid in C99 [-Wimplicit-function-declaration] free (p); ^ the only 2 warnings before were in strerror_r.c: /home/builder/.termux-build