[SOLVED] AArch64 running x86-64 binaries using qemu-system

[Luca91]

Hi all,
today I created an ArchLinuxArm VM using ArchBoot in my MacBook with M1 (Apple Silicon).
I need to run a couple of binaries built for x86-64 so I installed qemu-user and qemu-user-binfmt, but when I try to run any x86-64 executable I get:
$this->bbcode_second_pass_code('', 'qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory')

I'm a bit confused as this is the first time I'm trying to emulate something using qemu-user.
How should I install the required x86-64 libraries? Is there any package that provide them?

Thanks a lot,
Luca

[robg]

Could you please post the exact steps (commands) you took to run the x86-64 binary?

[Luca91]

Hi robg thank you for your reply.
Sure, here is what I did.

1) Install those two packages using pacman: $this->bbcode_second_pass_code('', 'sudo pacman -S qemu-user qemu-user-binfmt')
2) Download and unzip the x86-64 app that I need to run
3) Launch this app using: ./appname

Nothing special, really. I think that I have to install the corresponding x86-64 libs, so qemu can use them, but I can't find the right package tho.

[Luca91]

SOLVED!

What I did was manually download glibc-2.37 package from official ArchLinux repo and extract that .so library in /lib64.

In the future, I'd like to see a better way to get x86-64 dependencies from ArchLinuxArm. I think it would help a lot in these situations.

[robg]

Glad you got it working!

I am not sure we have gotten to the bottom of the actual issue though. Can you perhaps try if the executable runs properly when you install qemu-user-static and qemu-user-binfmt-static (instead of the non-static flavor)?

It is weird that the x86-linker is not provided by any QEMU package. For example, this is not the case for x86 (32bit) emulation where the linker is part of the qemu-system-x86 package.

[Luca91]

Hi robg,
qemu-user-static and qemu-user-binfmt-static are not available on the repository, that's why I installed the non-static version.

[robg]

Alas, I now recall that the QEMU packages on ALARM got garbled last year due to some difficult-to-port changes upstream. Apparently this is still unresolved.

I seems then that your solution is for the moment the only viable one. Thanks again for sharing!