Compilation failure against Android NDK r14 beta 2

[yan12125]

BPO	29436
Nosy	@vstinner, @skrah, @xdegaye, @yan12125
PRs	bpo-29436: fix compilation failure on Android since NDK r14 beta 2 #159
Files	nl_langinfo.patch: Requires autoreconf langinfo.h: langinfo.h from Android NDK

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2017-02-18.17:45:10.432>
created_at = <Date 2017-02-03.16:56:30.950>
labels = ['build', '3.7']
title = 'Compilation failure against Android NDK r14 beta 2'
updated_at = <Date 2017-02-19.17:43:58.106>
user = 'https://github.com/yan12125'

bugs.python.org fields:

activity = <Date 2017-02-19.17:43:58.106>
actor = 'xdegaye'
assignee = 'none'
closed = True
closed_date = <Date 2017-02-18.17:45:10.432>
closer = 'xdegaye'
components = ['Build']
creation = <Date 2017-02-03.16:56:30.950>
creator = 'yan12125'
dependencies = []
files = ['46503', '46504']
hgrepos = []
issue_num = 29436
keywords = ['patch']
message_count = 11.0
messages = ['286877', '286878', '288079', '288080', '288082', '288083', '288084', '288085', '288124', '288129', '288148']
nosy_count = 4.0
nosy_names = ['vstinner', 'skrah', 'xdegaye', 'yan12125']
pr_nums = ['159']
priority = 'normal'
resolution = 'later'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue29436'
versions = ['Python 3.7']

[yan12125]

Since Android NDK r14 beta 2, unified headers provide langinfo.h but there's no nl_langinfo() in it, causing linking failures:

libpython3.7m.a(pylifecycle.o): In function get_locale_encoding': /home/yen/Projects/python3-android/src/cpython/Python/pylifecycle.c:234: undefined reference to nl_langinfo'
libpython3.7m.a(fileutils.o): In function _Py_device_encoding': /home/yen/Projects/python3-android/src/cpython/Python/fileutils.c:65: undefined reference to nl_langinfo'
libpython3.7m.a(_localemodule.o): In function PyLocale_nl_langinfo': /home/yen/Projects/python3-android/src/cpython/./Modules/_localemodule.c:447: undefined reference to nl_langinfo'

Or compiler errors due to implicit function declarations if the patch at bpo-22747 is applied.

nl_langinfo.patch fixes it by adding some extra guarding macros.

Added some people from bpo-22747 to the nosy list, where the last change about langinfo.h and Android occurred.

[yan12125]

Here's a copy of $ANDROID_NDK/sysroot/usr/include/langinfo.h. (/sysroot/ stores unified headers [1]) To use those headers correctly, packagers have to add -D__ANDROID_API__=XY to CPPFLAGS. On the other hand, __ANDROID_API_FUTURE__ is defined in $ANDROID_NDK/sysroot/usr/include/android/api-level.h:

/*
 * Magic version number for a current development build, which has
 * not yet turned into an official release.
 */
#ifndef __ANDROID_API_FUTURE__
#define __ANDROID_API_FUTURE__ 10000
#endif

As a result nl_langinfo() does not exist in all real API versions.

[1] https://android.googlesource.com/platform/ndk.git/+/master/docs/UnifiedHeaders.md

[yan12125]

I've improved the patch and submitted it as PR 159. Now on Android:

1. _locale is built
2. _locale has several symbols, including CODESET
3. _locale doesn't have nl_langinfo()

Basically _locale maps what langinfo.h does. On Android langinfo.h has several #defines like CODESET but nl_langinfo() is missing from langinfo.h and libc.so.

On my ASUS ZE500KL, both test_locale and test_site (see: bpo-28596) pass.

[yan12125]

Well, I have to commit changes to configure and pyconfig.h, otherwise Travis tests fail. Maybe .travis.yml should call autoreconf first.

[vstinner]

Previously, we asked to not include generated files in patches, like
configure. With the new dev process (github, travis), you must now include
generated files.

[xdegaye]

I've improved the patch and submitted it as PR 159. Now on Android:

This is confusing. Android NDK r14 has not been released yet.
We do not develop CPython for platform beta releases.
Unified headers, the reason for your proposed change, are only introduced in NDK r14.
Any reason why you do omit mentioning these important facts in the issue ?
Maybe you think that Stephan, Victor and the other readers are aware of this ?
What about the time they waste reading this issue and your PR when this issue does not make sense with the NDK we are using (NDK r13) and is just a waste of time now ?
Why do you publish a PR ?

[xdegaye]

Closing this issue as 'later'.
Chi Hsuan Yen, I am still interested by your answers to my questions.

[yan12125]

Any reason why you do omit mentioning these important facts in the issue ?

Both in the title of this issue and that PR, I mention "NDK r14 beta 2". I'm not sure what you're referring to. On IRC, irker states the title first and then the comment content. I believe people will read the title first to determine whether they're interested or not. On email notifications of b.p.o and Github updates, the title is used as the email subject, so people can determine whether they want to see this email fast.

Maybe you think that Stephan, Victor and the other readers are aware of this ?

As explained above, I've already stated "beta" clearly

What about the time they waste reading this issue and your PR when this issue does not make sense with the NDK we are using (NDK r13) and is just a waste of time now ?

For me, reading the title takes a few seconds. If a developer thinks there's no need to support beta platforms, they can just ignore it.

Why do you publish a PR ?

This is a real issue. Usually NDK beta 2 is almost identical to the final release. For me it's good to fix things as soon as possible. There are some other examples for beta toolchains like bpo-1465, bpo-27806 or bpo-27596.

If you think issues on beta should be postponed until the final release, I can keep my patches locally and submit them later.

[xdegaye]

For me it's good to fix things as soon as possible.

The problem here is that you are attempting to push a change through a PR without providing the other core developers with important information. You should at least have given a reference to bpo-29040 and explain why you think it is safe to push this change now and not wait for the decision to switch to r14 and you should have done it *before* publishing the PR. By behaving this way, you may lead other core developers to think that you cannot be trusted.

If you think issues on beta should be postponed until the final release, I can keep my patches locally and submit them later.

Yes, please do. Note that this issue is closed for now anyway.
Also when you are running Python on Android and publishing some results on bpo (such as for example in bpo-29176) please make sure that Python has been built with r13.

[yan12125]

Thanks for the response. Sorry if my previous work on Android brings confusion.

To prevent possible wasting of time in the future, I'd like to confirm myself for some conclusions: CPython's support for Android targets only stable releases of the official NDK. That includes all building time and runtime results. I guess that's the current policy? Thanks in advance for any further replies.

[xdegaye]

CPython's support for Android targets only stable releases of the official NDK.

As the NDK is seeing many changes in the recent past and near future (deprecation of the support of gcc in favor of clang, Unified Headers, nearly all the NDK scripts written in python, ...) we should use the latest stable NDK release.

That includes all building time and runtime results.

You can open new issues for NDK r14 with the description of the problem and with NDK r14 building time and runtime results, as a reminder of what will need to be done when we switch to r14 as it was done for bpo-29040. But please no PR. Maybe add a comment saying that for the moment this is just a reminder.