New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android's incomplete locale.h implementation prevents cross-compilation #64504
Comments
As a result of Android's relatively incomplete locale.h implementation1, some functions are not defined and some standard structs are lacking fields (e.g. decimal_point, thousand_sep). Attached is a patch which works around the various issues posed by Android's locale.h implementation, mainly involving falling back to default locale values, causing compilation in that department for the author to succeed. |
I'd be +1 on such a patch if we were to officially support Android, but we'd need a volunteer to champion for this (which would be a good thing, IMO). Otherwise, such changes need to be maintained externally. |
I agree with Marc-Andre. Also, we should have an Android buildbot. |
Is there the only patch required to compile Python 3.4 on Android? |
I managed to cross-compile Python 3.3.3 for arm-linux-androideabi (using the Android NDK r9c) with the patches in this issue, bpo-20306 and bpo-20307. It did require a small additional patch which addressed the fact that the host system can't run the generated parser generator, which I'll make an issue for as soon as I refactored the patch. The patch allows the user to specify a host parser generator that points to a compiled version of pgen that is runnable on the host through the HOSTPGEN environment variable in ./configure. Compiling the tip proved somewhat harder as the cross-compilation requires a host Python of the same version, which I didn't have. I formatted a patch which allows the user to supply a special host python path using the HOSTPYTHON environment variable to ./configure. I'll make an issue for that soon, and will bundle it with the HOSTPGEN patch if it's seen as a sufficient approach. As far as maintaining an Android port for CPython goes; I may be interested in this as I'd need to regularly use it anyway. Can anyone tell me what the possibilities are here? Since in the meanwhile the tip was updated to unconditionally include locale.h in Python/fileutils.c according to bpo-19036, here's an updated patch for this issue that applies cleanly against the tip. |
Shiz <report@bugs.python.org> wrote:
There seem to be some external ports already. -- On the other hand, if we The problems with this are: a) In the past proponents of non-mainstream platforms have not been b) There were no build slaves (See http://www.python.org/dev/buildbot/) c) Many (or all) core committers did not have access to the platform Wikipedia claims that "QEMU also powers the Android emulator which is part of Running a build slave is rather easy, see: https://wiki.python.org/moin/BuildBot |
I'd say Android is quite a common platform these days, although I'd concur that it's not particularly easy to run Python OOTB on. :)
I've been looking into this, and the only option provided by the Android NDK involves cross-compiling Python on a regular machine. This would require some custom commands before and in between the builds, to build a host Python first, then cross-compile the Android Python, and then start the emulator, transfer the binaries there and run the tests over adb. Can buildbot provide functionality so this can be configured on-slave, or would it require setting up a seperate master? |
"I've been looking into this, and the only option provided by the Android NDK involves cross-compiling Python on a regular machine. This would require some custom commands before and in between the builds, to build a host Python first, then cross-compile the Android Python, and then start the emulator, transfer the binaries there and run the tests over adb. Can buildbot provide functionality so this can be configured on-slave, or would it require setting up a seperate master?" I'm not sure. Antoine, do you think this is possible? |
The master can ask the slave to execute arbitrary commands. So, as long However, the only point of setting up an Android buildbot would be if:
|
Consider the libmpdec part rejected. It is too much work given that |
Android NDK provides an "android-support" package [1]. There is no documentation other than README in its git repository, I guess it's a 'compatibility layer' between applications targetting a complete C library and Android's BioniC. With my patchset [2], Python builds and runs on my ASUS Zenfone 2 (Android 5.0.2). Patches proposed in this issue are no longer necessary. [1] https://android.googlesource.com/platform/ndk.git/+/master/sources/android/support/ |
Thank you, this is excellent! Does that mean that all locale patches are no longer needed? Here is one left (perhaps accidentally): https://github.com/yan12125/python3-android/blob/cpython-hg/mk/ncurses/android-locale-fixes.patch |
curses was broken and now it's fixed. Yes - Android's locale patch is no longer necessary in _curses either. However, there are runtime errors: shell@ASUS_Z00E_2:/data/local/tmp $ python3.6 -c 'import curses; curses.initscr()'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/data/local/tmp/python3/lib/python3.6/curses/__init__.py", line 30, in initscr
fd=_sys.__stdout__.fileno())
_curses.error: setupterm: could not find terminfo database |
This error: does not occur for me after removing the '--disable-database --disable-home-terminfo' options from the configure options used to cross-compile ncurses, and after setting the TERMINFO environment variable to a location where the the compiled description of the vt100 terminal is set. See https://bitbucket.org/xdegaye/pyona. Also, with API level 21 (Android 5.0), the build of python3 with the official android toolchains (that is, without resorting to external libraries for wide character support) runs correctly and the python test suite is run with few errors, so IMHO this issue may be closed. |
Thank you, closing this. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: