Emulator exited with code/signal 127 before debugger could connect.

[ssav7912]

Emulator exited with code/signal 127 before debugger could connect.

[Tiiffi]

Hello,

I am running this extension native on Linux and stumbled on the same problem.

On my machine the bundled fs-uae cannot open libSDL2_ttf-2.0.so shared object.

There are at least two workarounds:

1. Use LD_PRELOAD=/path/to/libSDL2_ttf-2.0.so ./fs-uae to launch the emulator (you might need to add more dependencies here)

2. Install missing library packages from your package manager (in my case libsdl2-ttf-2.0-0 on Debian / Ubuntu)

Note that this might happen with other shared objects too. Try running the bundled fs-uae manually to see what is happening.

Alternatively you can print bundled fs-uae shared object dependencies with ldd to see if some shared object dependencies are missing.

---

In addition to this problem I had to manually add execute flag to all bundled binaries.

[BartmanAbyss]

seems the emulator crashes before the debugger can connect. Can you try the regular windows version?

[ssav7912]

Can confirm the native windows version does work. WSL should be capable of calling to windows if invoking a windows executable, but I did try this on the winuae-gdb.exe and while WinUAE does launch, it locks up immediately. Running under windows works well though so not too concerned about making WSL behave.

[BartmanAbyss]

I suspect the problem is if you're using WSL that you're using the Linux version that comes with FS-UAE, probably that's not compatible with WSL. Any specific reason you're not using the native Windows version?

[BartmanAbyss]

@grahambates do we need to bundle that TTF library?

[grahambates]

We do currently bundle libSDL2_ttf-2.0.so.0 in the linux dir. I'll look into why this isn't being loaded in this case.

[Tiiffi]

Hi,

I'm not an expert on these things, but my understanding is that Linux doesn't look for dynamic libraries in the current path by default.

So my suggestion is to set environment variable LD_LIBRARY_PATH to . or '$ORIGIN' (or whatever is the correct library path) before launching the emulator.
This can be done via launch script or perhaps the vscode extension has already some other way to do it.

Shell script for example:

#!/bin/sh

# Set dynamic loader search path to current binary path and pass command line arguments ("$@")
LD_LIBRARY_PATH='$ORIGIN' /path/to/fs-uae "$@"

Alternatively, if you compile the emulator yourself, you can tell the linker to add a custom search path using the -rpath flag.

More details about the dynamic loader here: https://man7.org/linux/man-pages/man8/ld.so.8.html

---

Edit:

I had time to investigate bit further and looks like there was already this kind of thing in place:

vscode-amiga-debug/src/amigaDebug.ts

Line 556 in ae6e6c7

LD_LIBRARY_PATH: ".", // Allow Linux fs-uae to find bundled .so files

Changing LD_LIBRARY_PATH: "." to LD_LIBRARY_PATH: "$ORIGIN" seems to make it work properly.

Looks like "." alone points to project workspace directory.

Quote from manpage:

   $ORIGIN (or equivalently ${ORIGIN})
          This expands to the directory containing the program or
          shared object.  Thus, an application located in
          somedir/app could be compiled with

              gcc -Wl,-rpath,'$ORIGIN/../lib'

          so that it finds an associated shared object in
          somedir/lib no matter where somedir is located in the
          directory hierarchy.  This facilitates the creation of
          "turn-key" applications that do not need to be installed
          into special directories, but can instead be unpacked into
          any directory and still find their own shared objects.