Closed
Description
I just want to run arm-linux-gcc 4.4.3 :}
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install g++-multilib
sudo apt-get install libncurses5:i386
sudo apt-get install libc6:i386 libgcc1:i386 gcc-4.8-base:i386 libstdc++5:i386 libstdc++6:i386
sudo apt-get install lib32z1 lib32ncurses5 lib32ncursesw5 lib32ncursesw5-dev
Activity
therealkenc commentedon Sep 3, 2017
The User Voice was opened back up. If the embedded people were as organised as university students taking Machine Learning courses it would have a better chance.
poizan42 commentedon Sep 4, 2017
@plgkm6 That is quite an old gcc, do you need it for binary compatibility? Can't you just use 4.4.7? It is my understanding that gcc never breaks binary compatibility in minor releases. I believe you can just install the amd64 versions of the cross compiler from an older ubuntu version - you can find the softfloat version here and hardfloat version here. Select the amd64 built, you'll need the gcc-..._base_..., cpp-... and gcc-... packages at least.
For c++ support you will also need the g++-... and libstdc++6-4.4-dev-... packages.
If you really need gcc 4.4.3 then you could build a version for a 64-bit host yourself, there are plenty of guides on how to build gcc cross compilers.
therealkenc commentedon Sep 4, 2017
I was going to mention using the amd64 cross; but didn't because it isn't the root of (some of) the embedded guys' difficulty. The problem is many of their platform's supported build toolchains are stuck on 32-bit. Most notably Android, but also other embedded scenarios. Ref #1687, #1771, et al
MikeGitb commentedon Sep 6, 2017
Disclaimer: I'm a x64 zealot and I'm programming embedded systems down to 8bit microcontroller, but have almost no experience with Android development.
My hope would be that without 32 support, the tool vendors get more pressure to update their toolchains and I'd much rather see some progress on their side than resources being wasted on backwards compatibility on the WSL side.
therealkenc commentedon Sep 6, 2017
Yeah, me too a little. That said, you'd think Microsoft would be more sympathetic. My Visual Studio 2017 (August preview) is 32-bit, almost 15 years after Opteron was released. If the implication here is that Microsoft should encourage tool vendors like say Google to update, an obvious retort would be: "Whatever dude. You first."
Funny story if you are a 64-bit zealot.... The new ARM-powered Windows 10 laptops that are supposedly coming this Christmas have a 32-bit x86 emulator only. The laptops won't run amd64 apps. On a 64-bit Snapdragon. [I understand the reason; I just think it is funny.]
No word yet on whether they'll support WSL. 😉
fpqc commentedon Sep 6, 2017
@therealkenc I sorta wonder if they could actually leverage what they already have with WSL to ARM64. If I remember correctly, ADSS was originally designed to emulate Android on Windows phone (running on an ARM). Ubuntu has an ARM port, and that kind of userspace would be a natural thing to use in a WSL for ARM64. I guess I'm saying that it's interesting since part of the work seems like it's already done!
therealkenc commentedon Sep 6, 2017
@fpqc - [Squarely in discussion tag territory] Yeah I yanked Ben's chain on that in #1769 (message). It would be fun to see for the amusement value, but my (sometimes flawed) powers of deductive reasoning say "nah". Ubuntu userland isn't the problem. The kernel is technically feasible. The problem is the target platform is the cheapest of cheap laptops. Not exactly a 'development use case scenario'. There's only 7-8 people on the team, and they need another target platform to support like they need a bullet in the head. Maybe I am jaded by the fact that I have seen this show before, and the ending is always the same. No not Windows 10 RT. I am old enough to have seen Windows NT 3.1 on MIPS. "This too will pass". Or, maybe I'm wrong. Maybe someone upstairs will tell the team different. Carry the OneCore torch and all that. Or maybe they'll do it for the amusement value. Or... maybe developers will run out in droves to buy Snapdraggon powered laptops this Christmas.
poizan42 commentedon Sep 6, 2017
32-bit support could be fixed for probably 99% of programs by making a custom glibc, which anyone who feels up for it could do:
You can in fact run 32-bit code in WSL land. If you do a far jump to segment 0x23 then you are executing code in compatibility mode (i.e. 32-bit mode) - do a far jump to 0x33 to get back in 64-bit land. The problem is that WSL only supports 64-bit syscalls, so 32-bit code attempting to make syscalls won't work (and you can't trap them either, see #1655). I have a small demonstration that this is possible here: https://gist.github.com/poizan42/8ff01d3df80b1663afef775ca812b699
So if someone feel up for it then it should be possible to port glibc to "lol64" (Linux on Linux 64) that jumps to 64-bit mode to perform all the syscalls, and it should work for everything except fully static binaries and the rare stuff that makes syscalls without going through glibc (some emulation software possibly)
therealkenc commentedon Sep 7, 2017
Rare stuff, like
gdb
. Very cool hack though. #1655 was a good bug report by the way. I hope it gets addressed on the merits, nevermind the use case. Maybe ping a name-drop over there at some point. Good issue posts get lost/forgotten sometimes in all the noise.MikeGitb commentedon Sep 7, 2017
Actually I don't - That is, I can speculate, but if you have any actual information on this I would be thankful if you could share
therealkenc commentedon Sep 7, 2017
Well since you qualified the question, nope. I do not work at Microsoft, and even if I did, I couldn't share actual information like that. But I understand the reason.
MikeGitb commentedon Sep 8, 2017
@therealkenc: Just to be clear, with "actual" information I didn't mean "official" information, but more like "knowledge / reasonable assumptions I gathered from other posts or experience".
As I said, I myself can only speculate that it has to do with performance or reuse of code, but that is not even an educated guess, because I have no knowledge about where the pain points are when trying to run x86 or x64 code on an arm system or how Microsoft does it.
therealkenc commentedon Sep 8, 2017
There is never a single reason a company makes a decision. But my guess, for the price you've paid for it, is that it has at least partially to do with not running amok of instruction set patents with their emulator. 32-bit x86 is a smaller surface for Intel’s lawyers to attack, because most if not all of the juicy 32-bit x86 patents have expired. This makes the MSFT lawyer's jobs easier, and since these are
low endbattery optimised 4GB notebooks anyway, there is not a strong reason to make their lawyer’s jobs harder. It doesn't matter whether Intel has a legal leg to stand on, or not, of course. It would cost more for the in-house legal analysis, let alone risk a fight, than the entire engineering effort of the port.My basis for this hypothesis is that Microsoft, Qualcomm, Lenovo, and the rest don't want to have to advertise the 32-bit limitation any more than you want to hear it. Whatever the technical challenges of doing an amd64 emulator, which I suspect are marginal in the scheme, they are not high enough to justify having to explain to customers and all the Arstechnicas and Engadgets of the world that the machines don't run x64/amd64 binaries. Thus, I think the reasons are at least in part non-technical.
I could be wrong, IANAL, and all that.....
37 remaining items
Zypp commentedon Sep 18, 2018
This works like a charm, until I try to run my 32 bit executables in valgrind. My question already got shot down on stackoverflow for not being about programming. When I run valgrind I get
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
. Is there a fix or alternative method? My valgrind supports 32 bit, I verified this like in the answers here.drolevar commentedon Sep 27, 2018
I'm trying to launch java from openjdk-8-jre, and the java laucher cannot stat("/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so"), which doesn't return 0.
But the file itself exists.
I guess it has something to do with qemu, but so far I had no luck figuring it out.
ad-on-is commentedon Oct 6, 2018
I'm trying to use an ARM-crosscompiler. Unfortunatelly, I get these errors:
EDIT:
Nevermind, this was caused due to the fact that I migrated from macOS to Windows, which messed up the symlinks. After downloading and extracting the toolchain in WSL, everything worked fine ;-)
yanygm commentedon Nov 4, 2018
I hope to get 32-bit support on CentOS, what should I do?

Xinmudotmoe commentedon Nov 5, 2018
@yanygm
中文update-binfmts本质是调用了Linux内核,而binfmt_misc属于Linux内核功能。
你可以在centos上编译binfmt-support,或者使用向
/proc/sys/fs/binfmt_misc/register
写入数据获得与update-binfmts相似的功能。English translationThe essence of update-binfmts is to call the Linux kernel, and binfmt_misc is a Linux kernel feature.
You can compile binfmt-support on centos, or use the ability to write data to
/proc/sys/fs/binfmt_misc/register
to get similar functionality to update-binfmts.Reference: Kernel Support for miscellaneous (your favourite) Binary Formats v1.1 — The Linux Kernel documentation
Reference: #2468 (comment)
Biswa96 commentedon Nov 5, 2018
@zhang1813023404 Does it retain after restarting WSL?
Xinmudotmoe commentedon Nov 5, 2018
@Biswa96 When you reboot the operating system, or restart WSL, the configuration will be invalidated. If you want to maintain state, you may need to configure the $HOME/.bashrc file.
56 remaining items