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)

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.

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.

What is $HOSTPYTHON? It does not appear to be used or mentioned anywhere. You mention it as if it is commonly known, but if you are proposing a new configuration variable, perhaps you should document it.

The Gnu version of “which” seems to work fine with relative paths, though I know it is not a standardized command. Can you explain what your problem with relative paths is? Maybe we can find a cleaner way to check if a command exists, e.g. use “command -v”.

$ which ./python && echo Success
/media/disk/home/proj/python/cpython/python
Success

Can you explain the problem with PYTHONPATH and the —S addition? If we really need it, a comment would be good. What is the difference between your $HOSTPYTHON case and the original python3 etc cases, where it is not needed?

Also, did you test your patch? Your —S argument uses a UTF-8 em dash, which would be interpreted as a script file name, rather than an ASCII dash for the -S option.