-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
p4a create fails if cython is installed in ~/.local #771
Comments
I think it might be enough to invoke python.host with -s or PYTHONNOUSERSITE=1, which should disable ~/.local altogether |
p4a is supposed to use the local non-p4a cython binary. The problem here is that it does so (and apparently successfully), but then the pyjnius setup.py does something during the build that tries to import it, and naturally fails (since the targetpython build doesn't include cython). I'm not sure why this is happening though, and if removing cython from .local makes it work then it's certainly a weird interaction to avoid. |
This also seems to be happening with only a system cython installed, at least on Debian Jessie.
The testapp using flask and not kivy does compile. Is this the same issue? |
Looks like it could be. I'm still not sure why it's happening though. |
No, @kasperloopstra's issue is that it cannot find a cython. My issue is that it found the wrong one. This is happening because the recipes are extremely fragile and rely on the fact that nobody imports an extension module (_io, in this case). If, for varioius reasons, cython happens to be in sys.path, the setup.py tries to import it, triggering the crash. Why does it happens? I can think of at least two reasons:
I think that the real solution is to try to make the recipes less fragiles. In particular, they try to run "python setup.py build_ext" and expect it to fail to compile the .pyx files into C files. It should be sufficient to do a python setup.py sdist, and this has the advantage that can be done with whatever python you want, as long as it has cython installed. |
I see, I think I misunderstood the .local problem before. I'd be happy with any general improvement to the CythonRecipe mechanism. The current way is essentially inherited from the original python-for-android code, although I don't think it's quite as fragile as you suggest, since when we set the android environment up we totally replace the normal env vars, so the PYTHONPATH etc. are overridden (of course, it's certainly fragile in other ways). I agree about the expecting to fail, although I hadn't thought of using sdist to generate any build files without trying to cythonise. I've previously made some changes so that CythonRecipe could continue if the compile didn't fail, but I can't remember what I had done that made cython work here without any issues. I'll probably come back to this soonish to clean the whole thing up. Thanks for the information. |
I am sorry for my previous response, I now realize it sounded too harsh.
|
I'm not quite sure that it cannot find Cython at all. A few lines above the actual crash it does say: If it manages to find a Cython with the wrong ELFCLASS, this would cause this behaviour, right? I'll have a look at the Cython recipes this weekend and see if I can make some progress myself. |
I've hadded the '-s' switch to the calls to hostpython as @antocuni suggested, and changed the build_ext call to sdist as well. This results in a compiled APK, which then crashes on an Android x86 virtual machine when importing anything. I've tried the Flask and Kivy examples, and both seem to crash on the first import statement with an error in _io.so (has unexpected e_machine: 40). Does this mean that somehow modules are compiled with the host architecture? Or are modules being ignored when packing the APK? I will try some armeabi apk's once I've found a device newer than my own smartphone, in case it's just x86. |
@kasperloopstra If you'd like to debug this, please post the full logcat output. It would also be useful if you could open a PR (or just post the diff) with your recipe changes. |
Here's the diff and full log of me downloading, installing and running the APK's generated with that diff from the testapps for Flask and Kivy,
It seems that it's using some stuff from the armeabi arch. Which is wierd, as I've requested x86 on the commandline and I'm pretty sure I'm cleaning before each build. I'll run some other tests later today, but it kind of looks like x86 android isn't fully supported yet? I don't have any ARM devices near me (nothing with a recent android anyway), so testing that will have to wait for a while. Is there anything else that would help? |
When I added the arch stuff I confirmed that the x86 builds did work and could run in the emulator, so it should work in principle but I never tested it that much so there could be a bug either introduced since then or that I missed at the time. Your recipe changes look reasonable, I'll try to test these things individually later to check if they work for me. |
OK, this might be branching of in an entirely different issue now, but I'm not sure what's what. I've made a virtual Android ARM device (armeabiv7 android 4.4 AVD made with Android Studio), and when trying the Kivy app it crashes when trying to load SDL: ... .../AndroidRuntime( 1381): FATAL EXCEPTION: main When running the Flask app, it crashes in a different way, after extracting a whole load of Python files (what looks like most of numpy, among other things): ... .Which is odd as Ive compiled it with: Is there anything else I can do to debug this? I'll have a look at the arch stuff, but at first glance I couldn't find any obvious x86/armeabi typo's or switchups or something. Are there any known differences between armeabi AVD's and real hardware? |
Can any one tell me why this error is showing ?
|
@AnkitMArtin it seems unhappy about the spaces in your project path. please try in a path without any spaces in it.
this seems unrelated to this bug. |
Closing since it works for @AndreMiras, but if this is still an issue causing problems for people then feel free to reopen. |
I have cython installed in my ~/.local directory (I installed it using pip install --user cython, long ago).
When I try to create a distribution, it fails like this:
It seems that python.host tries to import Cython from there, but then cython imports io, which in turns imports _io and it fails.
If I remove Cython from ~/.local everything works fine. I didn't dig more but I assume that python.host is configured in a way to use a custom (or maybe just older?) version of Cython, which is masked by the one in ~/.local (which correctly overrides whatever it's in site-packages).
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: