[EMU] No suitable emulator binary Linux

[Vittek1978]

Fresh install, example workspace. Launch and task in vanilla state.

DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"

~/.vscode/extensions/prb28.amiga-assembly-1.8.2/dist/bin/fs-uae$ ./fs-uae-linux_x64

./fs-uae-linux_x64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./fs-uae-linux_x64)
./fs-uae-linux_x64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./fs-uae-linux_x64)

So this part is clear.

I tried to replace */dist/bin/fs-uae and build from source, renamig it to fs-uae-linux_x64. No joy. Any hints?

[prb28]

If your build works without a link error, you can try to reset the bindir: https://github.com/prb28/vscode-amiga-assembly/wiki/Breaking-Changes#binaries-are-embedded

[Vittek1978]

Moving the bindir to point to fs-uae breaks the vasm. This time I copied distribution provided fs-uae binaries to /resources/bin/linux/fs-uae and /dist/bin/fs-uae/fs-uae-linux_x64. They run fine in terminal from those locations. I also tried is a "emulatorBin" to point to distribution binaries. Is it deprecated? Problem remains.

[prb28]

The extension now uses the library https://github.com/grahambates/uae-dap from @grahambates. According to the readme, emulatorBin should work but I did not try it. The binaries are built for a u22.04, next week I'll try to run on a u20 vm, can you share a link to download you fs-uae build ?

[grahambates]

I'll look at changing the build job to compile on an older version for better compatibility.

[Vittek1978]

I looked at @grahambates code. My knowledge on ts is limited but it looks that you check if file exists and can be executed (chmod 755). customBin(emutatorBin) points to he right binary: "emulatorBin": "/home/.../.vscode/extensions/prb28.amiga-assembly-1.8.2/dist/bin/fs-uae/fs-uae-linux_x64" -rwxr-xr-x 1 mariusz mariusz 12281152 gru 19 2021 fs-uae-linux_x64 I downloaded it from fs-uae and replaced content of "dist" but the validation return false or there is something else going on in this area: public run(opts: RunOptions): Promise<void> { const customBin = opts.bin; const defaultBin = this.defaultBin(); let bin = customBin || defaultBin; if (customBin && !this.checkBin(customBin)) { logger.warn("Defaulting to bundled emulator binary"); bin = defaultBin; } if (!this.checkBin(bin)) { throw new Error("[EMU] No suitable emulator binary"); }

Binary used: https://fs-uae.net/files/FS-UAE/Stable/3.1.66/FS-UAE_3.1.66_Linux_x86-64.tar.xz

[nscendoni]

I had the same issue on Fedora 37, and I found out that in my case SDL2_ttf-2.20 was missing. Installing it resolved the issue.

[Regeneric]

Same problem on Arch Linux but @nscendoni is right - sdl2_ttf was missing. After installing it, FS-UAE works.

[paolopal]

Same issue here on Ubuntu 20, even worst, ldd command is reporting:

$ ldd fs-uae-linux_x64 ./fs-uae-linux_x64: /lib/x86_64-linux-gnu/libc.so.6: versionGLIBC_2.34' not found (required by ./fs-uae-linux_x64) ./fs-uae-linux_x64: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.33' not found (required by ./fs-uae-linux_x64) ... libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f2d98676000) libSDL2_ttf-2.0.so.0 => not found ...

In the same folder where fs-uae-linux_x64 is located, also the libSDL2 is present but quite sure that the path for libraries at operating system level has not been updated to include the folder, so the installation of the library could fix this issue. Overall, fs-uae-linux_x64 is really depending on the Linux OS distribution and release you are using, see dependency with specific version of glibc. Right way is to build fs-uae using static libraries (stored in same folder) and not dynamic ones. Also usage of standard libraries like glibc should be replaced by something like musl (https://musl.libc.org).

[adam-ainsworth]

I had this issue on Linux Mint, it transpires the binary won't run without SDL_ttf being installed. Running this sorted it for me

sudo apt-get install libsdl2-ttf-dev

[grahambates]

I've hopefully improved matters in the current version of uae-dap. It now includes a binary built on Ubuntu 20.04 so it uses an older glibc version, and it correctly sets LD_LIBRARY_PATH so that the bundled libraries are used.

I agree that to make the binary truly portable it needs to avoid dependencies on glibc etc as @paolopal suggests. I'll look into this, but this is a quick fix that should improve compatibility for now.

[grahambates]

I'll do some testing and open a PR with the dependency bump if it works as expected.

[pauljsymonds]

I am running on an M1 Mac and I get the following error, happy to help resolve if passed some pointers on where to make changes.

Emulator binary not found at '${extensionResourcesFolder}/bin/darwin/fs-uae' Defaulting to bundled emulator binary

It looks like the example launch.json file needed updating and it fixed it using information here

[prb28]

@pauljsymonds There is no binaries for M1 mac in uae-dap. @grahambates do you some spare time to update uae-dap for linux and mac ?

[grahambates]

That shouldn't be an issue, as you can use x86 binaries on M1 Mac with Rosetta, but it would still probably be good to add a native build at some point.

It is just a matter of updating the launch.json, as you no longer need to specify the emulator path. I'm happy to do this.

[pauljsymonds]

That shouldn't be an issue, as you can use x86 binaries on M1 Mac with Rosetta, but it would still probably be good to add a native build at some point.

It is just a matter of updating the launch.json, as you no longer need to specify the emulator path. I'm happy to do this.

Would what you describe here stop me from seeing the memory debug correctly on the M1 also?

I managed to get the demo working but the disassembly and debug when stepping didn't show what I had seen on Phaze101 tutorial.

[grahambates]

This is related to #273, which I'm planning to fix today.