libhoudini install breaks 32 bit waydroid #57

Open
opened 2022-11-15 11:43:18 -05:00 by dreamlayers · 4 comments
dreamlayers commented 2022-11-15 11:43:18 -05:00 (Migrated from github.com)

I'm running Waydroid in Ubuntu 22.10. The CPU doesn't support SSE4.2, so Waydroid installs 32-bit Android. It works. But then if I install libhoudini, it stops working. The only relevant error message I'm able to see is this in waydroid log:
lxc-start: waydroid: conf.c: run_buffer: 321 Script exited with status 126

This seems to be because of the way build props are set, including 64 abi props. I got Waydroid to work again by changing abi props to:

ro.product.cpu.abi=x86
ro.product.cpu.abilist=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi

After that I could install an app with 32 bit arm libraries. But then, trying to run it, I get this in logcat:

11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> AES << is not supported.
11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> POPCNT << is not supported.
11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> SSE4_2 << is not supported.
11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> PCLMULQDQ << is not supported.
11-15 16:33:10.658    45    45 I tombstoned: received crash request for pid 44041

So, at least this build of houdini can't actually run on my CPU. I wonder if houdini can be built without those requirements?

Edit: Installing libndk runs into the same problems. Again there is a need to edit system/build.prop the same way. Then when I try to run the app, it dies with SIGILL (illegal instruction) in the NDK library.

Using https://github.com/mirh/opemu-linux, which I needed to alter a bit to run with my kernel, the translators crash a different way instead. Opemu works well enough to make POPCNT work, but I guess there are some problems with other instructions.

I'm running Waydroid in Ubuntu 22.10. The CPU doesn't support SSE4.2, so Waydroid installs 32-bit Android. It works. But then if I install libhoudini, it stops working. The only relevant error message I'm able to see is this in `waydroid log`: `lxc-start: waydroid: conf.c: run_buffer: 321 Script exited with status 126` This seems to be because of the way build props are set, including 64 abi props. I got Waydroid to work again by changing abi props to: ``` ro.product.cpu.abi=x86 ro.product.cpu.abilist=x86,armeabi-v7a,armeabi ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi ``` After that I could install an app with 32 bit arm libraries. But then, trying to run it, I get this in logcat: ``` 11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> AES << is not supported. 11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> POPCNT << is not supported. 11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> SSE4_2 << is not supported. 11-15 16:33:10.653 44041 44110 D houdini : [44110] Expected CPU feature >> PCLMULQDQ << is not supported. 11-15 16:33:10.658 45 45 I tombstoned: received crash request for pid 44041 ``` So, at least this build of houdini can't actually run on my CPU. I wonder if houdini can be built without those requirements? Edit: Installing libndk runs into the same problems. Again there is a need to edit `system/build.prop` the same way. Then when I try to run the app, it dies with SIGILL (illegal instruction) in the NDK library. Using https://github.com/mirh/opemu-linux, which I needed to alter a bit to run with my kernel, the translators crash a different way instead. Opemu works well enough to make POPCNT work, but I guess there are some problems with other instructions.
WesleyVanNeck commented 2023-01-11 14:30:00 -05:00 (Migrated from github.com)

update your hardware

update your hardware
dreamlayers commented 2023-01-12 16:10:09 -05:00 (Migrated from github.com)

It would be nice if waydroid_script refused to install Houdini on 32 bit Waydroid instead of breaking Waydroid.

It would be nice if waydroid_script refused to install Houdini on 32 bit Waydroid instead of breaking Waydroid.
ayasa520 commented 2023-01-19 22:57:45 -05:00 (Migrated from github.com)

There are 3 versions of Houdini:

x: arm32 translation for x86
y: arm32 translation for x86_64
z: arm64 translation for x86_64

But after Android11, only y and z exist.

There are 3 versions of Houdini: ``` x: arm32 translation for x86 y: arm32 translation for x86_64 z: arm64 translation for x86_64 ``` But after Android11, only y and z exist.
mirh commented 2024-11-26 09:38:36 -05:00 (Migrated from github.com)

Houdini is closed source, so you can't really do much about it.
I can guess that the library has these bullshit requirements (seriously, AES-NI? lol) because they were targetting and really trying to squeeze their silvermont tablets. And I don't really know anything that emulates that, except perhaps SDE.
Idk about libndk which is really even more undocumented, but it's probably the same story (if not worse, who knows perhaps they targeted ryzens with AVX? you should really check your crash dumps with gdb to see which instruction faults). Did you try this?

Or another idea could be to try older versions of libhoudini (probably a process that comes way smoother if trying older android/rom versions altogether). The thing actually started with Medfield in 2012 (i.e. Saltwell) whose SSSE3 support is already a miracle (and the actual minimum requirement). So you shouldn't have a problem with your Core 2.
p.s. there is also some qemu-user magic floating around..

Houdini is closed source, so you can't really do much about it. I can guess that the library has these bullshit requirements (seriously, AES-NI? lol) because they were targetting and really trying to squeeze their silvermont tablets. And I don't really know anything that emulates that, except perhaps [SDE](https://www.intel.com/content/www/us/en/developer/articles/tool/software-development-emulator.html). Idk about libndk which is really even more undocumented, but it's probably the same story (if not worse, who knows perhaps they targeted ryzens with AVX? you should really check your crash dumps with gdb to see which instruction faults). Did you try [this](https://github.com/Slappy826/libndk-fixer)? Or another idea could be to try [older versions](https://groups.google.com/g/android-x86/c/VfhGHWrv3tM) of libhoudini (probably a process that comes way smoother if trying older android/rom versions altogether). The thing actually [started](https://www.anandtech.com/show/5365/intels-medfield-atom-z2460-arrive-for-smartphones/5) with Medfield in 2012 (i.e. Saltwell) whose SSSE3 support is already a miracle (and the actual [minimum requirement](https://groups.google.com/g/android-x86/c/AIGZe_q348s/m/KAEJU0pkAwAJ)). So you shouldn't have a problem with your Core 2. p.s. there is also some qemu-user [magic](https://github.com/goffioul/ax86-nb-qemu/issues/2) floating around..
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wbruno/waydroid_script#57