X86 Compatibility Layer

Librem Phones (Librem 5)
#1

I anticipate wanting to run some Linux applications on my Librem 5 (after it arrives), that were compiled to run on x86.

Some programs just don’t get compiled to run on ARM64. I called Oracle once looking for a compiler for ARM64. They wanted to know everything about my employer and what the compiler would be used for. When they found out I didn’t represent my employer and it was just for me, they found a polite way to tell me to get lost.

This was several years ago. I found a compatability layer called Exagar then. It is no longer sold now. But back then, it was sure convenient. On a rooted phone in a Linux chroot terminal window with Exagear installed, I could type-in “arch” which returned “ARM64”. Then I would type-in “Exagear”, and could then type-in “arch” which would return “i386”. When in i386 mode, I could install and run PC programs (on my phone). When in “ARM64” mode, I could install and run ARM programs. It was really easy to go back and forth and use either instruction set. I built my i386 program shortcut scripts to invoke Exagar first, before execution. Both instruction sets lived next to eachother on that phone and both worked equally.

Does a similar tool exist currently, that will work well on the Librem 5? Is there a free and easy way to get ARM compiler available anywhere? The way Oracle acts, one would think it’s illegal to compile an ARM program without their permission. And they only want to deal with big companies. I got the impression that that Exagear guy (apparently a one-man company somewhere in Europe) likely got driven out of business by lawyers. He seemed happy, very communicative, and was doing a good amount of business until one day he just shut down without saying why.

#2

Compiling converts source code into machine code. Once something is compiled, you need an emulator to run on another type of machine. It does not make sense to compile machine code. Compilers for source code are free and come with every Linux distribution. They can compile to many different CPU types, including ARM64. Emulators are usually very slow unless the CPU has something that speeds this up. QEMU can emulate, but it I would guess that it would be unusable on the Librem 5, but that is just a guess.

When you call Oracle, you first talk to a sales person whose first task is to figure out what you can afford. Oracle sues its own customers for turning features on that they did not purchase and provides little value above what you can find in PostgreSQL, which also has competing professional support companies. The reason why companies use Oracle is that it is expensive to change databases once you have built a lot of code that relies on it, and some very expensive enterprise software only supports it.

Most open source Linux applications compile to ARM64. However, closed source applications tend to only target what their paying customers use.

#3

So are you saying that anyone can compile programs to run in ARM architecture and that the compiler is free? Apparently still though, a compatibility layer can allow proprietary x86 programs to be run on an ARM machine.

#4

Because of the Raspberry Pi (and other single board computers) and Apple M1 CPUs, almost everything in the open source world already compiles to ARM64. And yes, the compiler that they use is free (gcc or clang). But with Linux distributions, like PureOS and Debian, they compiled programs for you and you just need to use their package manager to install the application (sudo apt-get install).

An emulator for the machine code is only part of the problem. Other problems include the screen size and lack of a physical keyboard and mouse if you are wanting to run something meant for a laptop or desktop. If you need access to proprietary applications from the phone, consider installing a VNC or RDP client on the phone and running the application on a real x86 with Remote Desktop enabled or a VNC server installed. This also gives you more memory to work with, and some remote desktop clients let you scale the graphics and provide an on-screen keyboard.

#5

Good news, the Librem 5 has an ARM64 compiler (or two) available to download on default install. apt install gcc.

https://packages.debian.org/search?suite=bullseye&section=all&arch=any&searchon=names&keywords=gcc

https://packages.debian.org/search?suite=bullseye&section=all&arch=any&searchon=names&keywords=clang

If you’d prefer to emulate, then there’s an emulator, too:

https://packages.debian.org/search?suite=bullseye&section=all&arch=any&searchon=names&keywords=qemu-user-static

1 Like
#6

Just a bit more information so that previous responses don’t appear disingenuous:
Barring recompiling or using an emulator, you can also use something else which is called a translation layer. This is what wine does, for example. It is also how M based Macs can run x86 based software.

The advantages are that there is no need for a recompile and speed should be better than on emulation. Simply recompiling an application isn’t always possible for a host of reasons. This is why a translation layer is ideal and I think would be a great option for the Librem 5, should something like that be possible.

#7

I would be very interested if somebody reports experience with QEMU on Librem 5.
I have not used QEMU in the past (only VirtualBox with a GUI on x86 Debian) so a review of somebody putting QEMU on Librem 5 into work would be useful to get on speed.

#8

You can’t use a translation layer (like Wine in the technical sense) to run x86 software on other CPU architectures. You have to use full emulation like QEMU (although you might consider it a translation layer in a different sense than Wine) or Apple’s Rosetta.

If you want to use QEMU on the L5, trying qemu-system-user on a random Linux executable should be a half hour exercise (10 minutes if you used it before).

2 Likes
#9

Yeah I guess it might be a bit of symantics, but I still see it more as a translation layer than as emulation. Perhpas it would be more fair to call it a hybrid of the tow methods.

#10

It might be a hybrid to some small extent, but you can’t do that wihout emulation (what Wine does not do) and you might get away without Wine-like translation.
Wine’s task is to pretend that it’s Windows by changing calls from one OS to entirely different ones on another OS - translating them. When the architecture changes but the OS stays Linux, you might have to adjust the encoding of some calls, but that’s orders of magnitude easier.

So I’d say it’s definitely more of emulation than anything else.

1 Like
#11

In the C language, all memory can be executed as code or treated as data. You can translate the binaries to some degree, but there will always be some runtime translation, and that tends to make things very slow, unless the CPU has some trick that it can use to speed it up, like speculative execution, which can cause problems with security. This is rather demanding for a phone that has 3GB of RAM and is supposed to be power efficient. In other words, to run x86 quickly, the CPU has to do a lot of things that consume power and get wasted because it does not know which speculation is correct until later.

#12

That’s not merely a matter of language, but more fundamental: it’s the property of the von Neumann processor architecture, as opposed to the Harvard architecture. You can change between them on the level of a language, but that’s rarely used deliberately.

Speculative execution, when supported by the CPU, is enabled always, so it doesn’t really matter what is getting executed. Speculation is just part of the CPU architecture (check out “branch prediction”).

1 Like