Re: Merging feature/android

[Po Lu]

Paul Eggert <eggert@cs.ucla.edu> writes:

> That's likely an earlier version of Sun C that does not support
> __attribute__ ((cleanup)). I doubt whether it's worth worrying about
> these older Sun C versions. People can get an up-to-date compiler, or
> (better yet) use GCC. It's not worth our time to port to obsolete Sun
> C.

But nothing prevents us from making this tiny change to our configury to
make Emacs work with those old compilers.

>> the correct solution is to check whether or not the compiler
>> supports such an extension, and disable dynamic module support should it
>> not.  Which is why we use configure in the first place, instead of
>> performing ``checks'' with `GNUC_PREREQ'.
>
> Emacs uses HAS_ATTRIBUTE, which should use Clang's __has_attribute,
> which should work with a recent-enough Android NDK (as these are based
> on Clang).
>
> If you're using an older Android NDK based on GCC, yes that does use
> GNUC_PREREQ, but again this should work unless the older Android NDKs
> are squirrelly about GCC version numbers (are they?).

The problem with GNUC_PREREQ is that while it works as intended, the
check in emacs-module.c doesn't catch the r16 gcc which throws ICEs
compiling a program, and the fallback is not to disable dynamic module
support, but to cause a compilation error.

> It's true that the Autoconf Way is to write a little program to test
> for __attribute__((cleanup)) directly, and that may be a good way to
> go. However, I would suggest first understanding why the current
> approach does not work. (But please see below; perhaps we don't need
> to worry about this at all.)

It is best to follow the Autoconf Way.  Otherwise, we will be heading
back to the age where configure looked for the a m/ header and then ran
Makefile.c through sed and cpp.

> Although I'm sure that ancient Android versions are still used
> somewhere, I suggest that we not worry about porting to Android
> versions so old that Google itself no longer supports them. This is
> the general guideline we've used for most other ports, and it should
> be a good guideline for Android too. We have limited development
> resources and it's generally not worth our time to port to an OS if
> it's not even worth the OS maintainer's time to support the OS.
>
> Plus, Emacs is likely to have known security holes if we try to port
> it to no-longer-supported Android, and that would be bad for our users
> and bad publicity for Emacs. Android is one of the biggest malware
> targets out there.

I cannot agree with this statement when I see every day my relatives and
coworkers using such old versions of Android, which are also supported
by many proprietary software developers.

An old version of the NDK works fine, and is in fact still supported by
Google (r16 is provided in the SDK manager's downloads page as an LTS
release), aside from having this nasty compiler problem.