GNU bug report logs - #65319
compilation error on Android (Termux)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65319 in the body.
You can then email your comments to 65319 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnu-emacs <at> gnu.org, Po Lu <luangruo <at> yahoo.com>
Subject: compilation error on Android (Termux)
Date: Tue, 15 Aug 2023 22:28:25 +0200

Hi,

Compiling a current Emacs checkout from today on Android, inside the Termux
app, produces a compilation error:

../../src/dired.c:1140:16: warning: call to undeclared function 'getpwent'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  while ((pw = getpwent ()))
               ^
../../src/dired.c:1140:14: error: incompatible integer to pointer conversion assigning to 'struct passwd *' from 'int' [-Wint-conversion]
  while ((pw = getpwent ()))
             ^ ~~~~~~~~~~~

The reason is that the default Android API level in Termux is 24,
the Android <pwd.h> declares getpwent() only starting with API level 26:

  #if __ANDROID_API__ >= 26
  struct passwd* getpwent(void) __INTRODUCED_IN(26);
  ...

yet HAVE_GETPWENT and HAVE_ENDPWENT come out as 1.

I can see two possible fixes:
  a) use
       gl_CHECK_FUNCS_ANDROID([getpwent], [[#include <pwd.h>]])
     instead of
       AC_CHECK_FUNCS(... getpwent ...)
     in configure.ac,
  b) add
       AC_CHECK_DECLS([getpwent], [], [], [[
         #include <sys/types.h>
         #include <pwd.h>
         ]])
     to configure.ac, and a '&& HAVE_DECL_GETPWENT' in
     src/dired.c line 1137.

Bruno

Message #8 received at 65319 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 65319 <at> debbugs.gnu.org
Subject: Re: bug#65319: compilation error on Android (Termux)
Date: Wed, 16 Aug 2023 09:35:59 +0800

Bruno Haible <bruno <at> clisp.org> writes:

> Hi,
>
> Compiling a current Emacs checkout from today on Android, inside the Termux
> app, produces a compilation error:
>
> ../../src/dired.c:1140:16: warning: call to undeclared function 'getpwent'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
>   while ((pw = getpwent ()))
>                ^
> ../../src/dired.c:1140:14: error: incompatible integer to pointer conversion assigning to 'struct passwd *' from 'int' [-Wint-conversion]
>   while ((pw = getpwent ()))
>              ^ ~~~~~~~~~~~
>
> The reason is that the default Android API level in Termux is 24,
> the Android <pwd.h> declares getpwent() only starting with API level 26:
>
>   #if __ANDROID_API__ >= 26
>   struct passwd* getpwent(void) __INTRODUCED_IN(26);
>   ...
>
> yet HAVE_GETPWENT and HAVE_ENDPWENT come out as 1.
>
> I can see two possible fixes:
>   a) use
>        gl_CHECK_FUNCS_ANDROID([getpwent], [[#include <pwd.h>]])
>      instead of
>        AC_CHECK_FUNCS(... getpwent ...)
>      in configure.ac,
>   b) add
>        AC_CHECK_DECLS([getpwent], [], [], [[
>          #include <sys/types.h>
>          #include <pwd.h>
>          ]])
>      to configure.ac, and a '&& HAVE_DECL_GETPWENT' in
>      src/dired.c line 1137.
>
> Bruno

Thanks.  What does config.guess say in Termux?  And are you trying to
build the Android port on Android, or just Emacs itself?

P.S: our bug tracker intercepts all mail and resends individual messages
itself, so you must use the X-Debbugs-Cc header instead of the carbon
copy list when initially opening a bug.  If you don't, I get the message
you send to the bug tracker, instead of the message it resends.

Thanks.

Message #11 received at 65319 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 65319 <at> debbugs.gnu.org
Subject: Re: bug#65319: compilation error on Android (Termux)
Date: Wed, 16 Aug 2023 03:49:42 +0200

Po Lu wrote:
> What does config.guess say in Termux?

Both build-aux/config.guess and exec/config.guess return
  armv7l-unknown-linux-gnueabi
but I configure all packages with
  --host=armv7l-linux-androideabi
so that all tests of "$host_os" see that it's Android and not an
arm system with glibc.

> And are you trying to
> build the Android port on Android, or just Emacs itself?

I took the Emacs sources from git, generated the 'configure' file, and
am compiling it like I compile on other POSIX-like systems. The Emacs
specific configure options that I use are --without-all --without-x.

Bruno

Message #14 received at 65319 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 65319 <at> debbugs.gnu.org
Subject: Re: bug#65319: compilation error on Android (Termux)
Date: Wed, 16 Aug 2023 11:15:05 +0800

Bruno Haible <bruno <at> clisp.org> writes:

> I took the Emacs sources from git, generated the 'configure' file, and
> am compiling it like I compile on other POSIX-like systems. The Emacs
> specific configure options that I use are --without-all --without-x.

OK, thanks; I'm surprised this configuration functions at all,
considering that it has never been tested.

Does Gnulib guarantee that the gl_CHECK_FUNCS_ANDROID stuff will
continue to exist in the future?  If so, I'm inclined towards using
that.

Message #17 received at 65319 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 65319 <at> debbugs.gnu.org
Subject: Re: bug#65319: compilation error on Android (Termux)
Date: Wed, 16 Aug 2023 11:50:11 +0200

Po Lu wrote:
> Does Gnulib guarantee that the gl_CHECK_FUNCS_ANDROID stuff will
> continue to exist in the future?  If so, I'm inclined towards using
> that.

Yes. This macro is used over 100 times in Gnulib, has not seen any
problem reports in the last 6 months, and is prefixed with 'gl_'
not '_gl_'. Therefore it's very unlikely to go away.

Note this macro's documentation:

...
dnl Thus, the question "does the OS have the function func" has three possible
dnl answers:
dnl   - yes, in all versions starting from the given API level,
dnl   - no, in no version,
dnl   - not in the given API level, but in a later version of Android.
...
dnl This macro sets two variables:
dnl   - gl_cv_onwards_func_<func>   to yes / no / "future OS version"
dnl   - ac_cv_func_<func>           to yes / no / no
dnl The first variable allows to distinguish all three cases.
dnl The second variable is set, so that an invocation
dnl   gl_CHECK_FUNCS_ANDROID([func], [[#include <foo.h>]])
dnl can be used as a drop-in replacement for
dnl   AC_CHECK_FUNCS([func]).

Bruno

Message #22 received at 65319-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 65319-done <at> debbugs.gnu.org
Subject: Re: bug#65319: compilation error on Android (Termux)
Date: Wed, 16 Aug 2023 20:33:36 +0800

Bruno Haible <bruno <at> clisp.org> writes:

> Po Lu wrote:
>> Does Gnulib guarantee that the gl_CHECK_FUNCS_ANDROID stuff will
>> continue to exist in the future?  If so, I'm inclined towards using
>> that.
>
> Yes. This macro is used over 100 times in Gnulib, has not seen any
> problem reports in the last 6 months, and is prefixed with 'gl_'
> not '_gl_'. Therefore it's very unlikely to go away.
>
> Note this macro's documentation:
>
> ...
> dnl Thus, the question "does the OS have the function func" has three possible
> dnl answers:
> dnl   - yes, in all versions starting from the given API level,
> dnl   - no, in no version,
> dnl   - not in the given API level, but in a later version of Android.
> ...
> dnl This macro sets two variables:
> dnl   - gl_cv_onwards_func_<func>   to yes / no / "future OS version"
> dnl   - ac_cv_func_<func>           to yes / no / no
> dnl The first variable allows to distinguish all three cases.
> dnl The second variable is set, so that an invocation
> dnl   gl_CHECK_FUNCS_ANDROID([func], [[#include <foo.h>]])
> dnl can be used as a drop-in replacement for
> dnl   AC_CHECK_FUNCS([func]).
>
> Bruno

Thanks.  I'll install the change you proposed in short order, and am
closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.