Repository navigation
Support for 32-bit i386 ELF binaries #390
Description
Currently it does not seem to be possible to execute 32-bit Linux ELF binaries in BashOnWindows environment. An attempt to execute an 32-bit ELF binary fails with the following error:
bash: ./program: cannot execute binary file: Exec format error
Adding i386 architecture to dpkg and installing i386 versions of relevant libraries (libc6, libncurses5, libstdc++6) does not help.
Generally this is not a big deal if the source of the program is available in a way or another, however, there is quite a lot of 32-bit proprietary tools that are distributed in binary-only form, and currently those are unusable within BashOnWindows.
Reacted by Adrian Frühwirth, Ev Dolzhenko, fcying, Robbie Gifford, Jeff McGlynn, Tom, Gwynbleidd, Ajay Bhargav, Alex Cohn, Gh0stBlade and 11 more
Activity
stehufntdev commentedon May 18, 2016
Thanks for trying out WSL! Currently WSL only supports amd64 (native 64bit), and this was brought up in #228 as well.
To get this on our priority list can you add it to our UserVoice?
rtiainen commentedon May 18, 2016
Similar item is already on the UserVoice as follows:
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13377507-please-add-32-bit-elf-support-to-the-kernel
Timvrakas commentedon Mar 17, 2017
Could we have the message returned when 32 bit binaries are run mention this limitation. Its not a big problem but I was a head scratcher for a bit.
yuhong commentedon Jul 7, 2017
I wonder how they will deal with syscall/sysenter and the vDSO or will they just use int 80h?
ffainelli commentedon Apr 7, 2019
You can work around this with installing 'qemu-user' and running your programs with "qemu-i386 ", not the fastest thing in the world, but if you are stuck with 32-bit binaries (not sources), that should do it.
MPeti1 commentedon Feb 22, 2021
The above mentioned uservoice instance is no longer available (or at least it says so to me), so I think this issue should be reopened.
Unless the devs don't want to deal with this problem, in which case it would be nice to have an official statement (at least in this issue) regarding that.
Blue (@OneBlue) (tagging you because you seem to be the only active dev nowadays)
windowsair commentedon Feb 22, 2021
WSL1 has ceased development. This problem does not exist in WSL2.
GitMensch commentedon Apr 22, 2021
The likely sole question is: even if WSL2 is installed and used on a system, installing another distro via MS Store still installs it with with WSL1 - Why? (works after manual upgrade via
wsl --list --verbose+wsl --set-version $distro_name 2)deven commentedon Sep 17, 2021
Workaround using QEMU: https://stackoverflow.com/a/49405605/1003451