[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail
Shiz added the comment: Ah, yes, if it's not actually mandated by POSIX, something like HAVE_PASSWD_PW_GECOS would be more appropriate. I'll rework the patch into something more generic. -- ___ Python tracker <http://bugs.python.org/issue20306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.
New submission from Shiz: Currently, when cross-compiling, the configure script doesn't take $HOSTPYTHON into account when determining $PYTHON_FOR_BUILD. This can lead to a wrong Python interpreter being used for several critical cross-compilation stages, leading to compilation errors[1]. Attached is a patch which makes it take $HOSTPYTHON into account, thus solving said issues, diffed against the current hg tip, 723e0a7c4914. [1]: https://github.com/rave-engine/python3-android/issues/1 (the last issue in the report) -- components: Cross-Build files: Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection.patch keywords: patch messages: 224230 nosy: shiz priority: normal severity: normal status: open title: Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD. type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36150/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection.patch ___ Python tracker <http://bugs.python.org/issue22100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.
Changes by Shiz : -- versions: +Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue22100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.
Shiz added the comment: After some further investigation it seems the which-clause fails when given a relative path. Since we should expect $HOSTPYTHON to be present in the first place, I modified the patch a bit to special-case the $HOSTPYTHON check, and fall back on the other interpreters as checked before. -- Added file: http://bugs.python.org/file36181/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection-v2.patch ___ Python tracker <http://bugs.python.org/issue22100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.
Shiz added the comment: And a last tiny fix: on a lot of systems (except apparently the system I was using for my main testing), a freshly-built HOSTPYTHON will be confused to look for libraries, and the invocation will fail because it can't bootstrap itself. Point it to the current Python tree for libraries. -- Added file: http://bugs.python.org/file36247/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection-v3.patch ___ Python tracker <http://bugs.python.org/issue22100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20305] Android's incomplete locale.h implementation prevents compilation
New submission from Shiz: As a result of Android's relatively incomplete locale.h implementation[1], some functions are not defined and some standard structs are lacking fields (e.g. decimal_point, thousand_sep). This prevents proper cross-compilation using the Android NDK[2] from succeeding. 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. [1]: https://groups.google.com/forum/#!topic/android-ndk/PBK4KkRpDoU [2]: https://developer.android.com/tools/sdk/ndk/index.html -- components: Cross-Build files: Python-3.4.0tip-workaround-android-locale-issues.patch keywords: patch messages: 208486 nosy: shiz priority: normal severity: normal status: open title: Android's incomplete locale.h implementation prevents compilation type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33549/Python-3.4.0tip-workaround-android-locale-issues.patch ___ Python tracker <http://bugs.python.org/issue20305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20305] Android's incomplete locale.h implementation prevents cross-compilation
Changes by Shiz : -- title: Android's incomplete locale.h implementation prevents compilation -> Android's incomplete locale.h implementation prevents cross-compilation ___ Python tracker <http://bugs.python.org/issue20305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail
New submission from Shiz: As the title states, mkpwent() in pwdmodule.c accesses `pw_gecos`, which is not defined for struct passwd in Bionic, Android's C library. Attached is a patch that works around the issue by setting the field to None on Android. -- components: Cross-Build files: Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch keywords: patch messages: 208487 nosy: shiz priority: normal severity: normal status: open title: Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33550/Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch ___ Python tracker <http://bugs.python.org/issue20306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail
New submission from Shiz: Bionic, Android's C library, fails to expose the SYS_* constants used for the syscall(1) interface, which causes compilation of the _posixsubprocess module to fail as it directly attempts to call SYS_getdents64. Attached is an experimental patch that manually defines SYS_getdents64 from Bionic's internals. -- components: Cross-Build files: Python-3.4.0tip-expose-SYS_getdents64-on-android.patch keywords: patch messages: 208488 nosy: shiz priority: normal severity: normal status: open title: Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33551/Python-3.4.0tip-expose-SYS_getdents64-on-android.patch ___ Python tracker <http://bugs.python.org/issue20307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail
Shiz added the comment: I of course meant the syscall(2) interface, not syscall(1). -- ___ Python tracker <http://bugs.python.org/issue20307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20305] Android's incomplete locale.h implementation prevents cross-compilation
Shiz added the comment: I managed to cross-compile Python 3.3.3 for arm-linux-androideabi (using the Android NDK r9c) with the patches in this issue, issue 20306 and issue 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 issue 19036, here's an updated patch for this issue that applies cleanly against the tip. -- Added file: http://bugs.python.org/file33569/Python-3.4-d51d6f1f9db8-workaround-android-locale-issues.patch ___ Python tracker <http://bugs.python.org/issue20305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20305] Android's incomplete locale.h implementation prevents cross-compilation
Shiz added the comment: > c) Many (or all) core committers did not have access to the platform > in question. 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. :) >Wikipedia claims that "QEMU also powers the Android emulator which is part of >the Android SDK." Can you run a build slave with network access and also run >the test suite in this emulator? 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? -- ___ Python tracker <http://bugs.python.org/issue20305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail
Shiz added the comment: That's probably a good idea. Fixed patch attached. -- Added file: http://bugs.python.org/file33584/Python-3.4.0tip-expose-SYS_getdents64-on-android-v2.patch ___ Python tracker <http://bugs.python.org/issue20307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail
Shiz added the comment: Please take note of the discussion in issue 20305 if you were planning to merge this, by the way. -- ___ Python tracker <http://bugs.python.org/issue20307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25468] PyTraceBack_Print()/_Py_DisplaySourceLine() should take custom loaders into account
New submission from Shiz: Currently, when an error occurs in a module loaded through a loader in sys.meta_path with no direct file name correlation on the filesystem, the traceback source line is empty as such: File "/Users/mark/Development/Projects/Rave/rave/rave/game.py", line 65, in run self.window.render(None) File "/.modules/sdl2/video/window.py", line 86, in render File "/.modules/sdl2/video/window.py", line 259, in swap KeyboardInterrupt While the filename has no direct mapping on the file system, what it can do is just do the equivalent of module.__loader__.get_source('module') to retrieve the source code to find the appropriate line in, and only if that fails fall back on trying to interpret the module file name as a normal file system path. -- components: Interpreter Core messages: 253400 nosy: shiz priority: normal severity: normal status: open title: PyTraceBack_Print()/_Py_DisplaySourceLine() should take custom loaders into account type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25468> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23773] importlib does not properly remove frames when invoking external import hooks
New submission from Shiz: When adding a custom module loader to sys.meta_path, importlib does not properly remove its frames before invoking it. This results in a weird traceback with importlib._bootstrap frames in if an error occurs during load_module(), like such: Traceback (most recent call last): File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 102, in bootstrap_game __import__(MODULE_PACKAGE + '.' + mod.replace('.py', '')) File "", line 2237, in _find_and_load File "", line 2226, in _find_and_load_unlocked File "", line 1200, in _load_unlocked File "", line 1129, in _exec File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module super().exec_module(module) File "/.modules/opengl/__init__.py", line 1, in from . import common, core3 File "", line 2237, in _find_and_load File "", line 2226, in _find_and_load_unlocked File "", line 1200, in _load_unlocked File "", line 1129, in _exec File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module super().exec_module(module) File "/.modules/opengl/core3/__init__.py", line 11, in from .texture import Texture, Image File "", line 2237, in _find_and_load File "", line 2226, in _find_and_load_unlocked File "", line 1200, in _load_unlocked File "", line 1129, in _exec File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module super().exec_module(module) File "/.modules/opengl/core3/texture.py", line 8, in raise ValueError Attached is a patch against the current hg head that makes sure module loaders are invoked through _call_with_frames_removed, so that the output becomes a lot more readable: Traceback (most recent call last): File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 102, in bootstrap_game __import__(MODULE_PACKAGE + '.' + mod.replace('.py', '')) File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module super().exec_module(module) File "/.modules/opengl/__init__.py", line 1, in from . import common, core3 File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module super().exec_module(module) File "/.modules/opengl/core3/__init__.py", line 11, in from .texture import Texture, Image File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module super().exec_module(module) File "/.modules/opengl/core3/texture.py", line 8, in raise ValueError ValueError Ideally it would remove the calls /within/ the module loader itself too, but I do not see an easy way to do this without changing the entire _call_with_frames_removed semantics. This fixes most of the issues, though. -- components: Library (Lib) files: cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch keywords: patch messages: 239219 nosy: shiz priority: normal severity: normal status: open title: importlib does not properly remove frames when invoking external import hooks type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38681/cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch ___ Python tracker <http://bugs.python.org/issue23773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23773] importlib does not properly remove frames when invoking external import hooks
Shiz added the comment: Ah, that is a very good point. I'll run the suite as soon as I find the time and will report back. -- ___ Python tracker <http://bugs.python.org/issue23773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com