Exec format error

Developers
1

I’m trying to run the pre-built linux binary for amulet, it says cannot execute binary file: Exec format error. It provides a i686 and a x86_64 binaries, both failed with same message.

The same error happens with any pre-built linux binaries, including love2d, unity, neovim… And I haven’t successfully manually compile anything on the device yet (with amulet I got builds/linux32/lua51/release/lib/libsdl.a: error adding symbols: File in wrong format).

What’s causing the problem? Is there anything I can do to make it work?

EDIT:
I learned that GameShell is running on ARM, and it’ll never run i686 and x86_64 stuff. I guess my best bet is to try to compile myself.

2

If there are packages you are looking for, try seeing if they have an “armhf” version available, which is the architecture the GameShell runs on. (also applies for RPi)

Try using apt to install libraries you need (like libsdl, some have a “-dev” suffix which is what you will likely need to build from source) and any source code that you try to compile should be able to look it up from the default include paths.

If there’s some thing you want to install I can probably try to guide you on it (Unity of the things you mentioned doesn’t have an ARM build though)

1 Like
4

Thanks for the help! Yeah I learned more about architectures and got a basic grasp on what’s going on. I currently want to bring amulet to GameShell since it’s another powerful tool that uses lua.

Unity is also a goal cuz we’re planning hosting an offline GameShell game jam and we want developers to be able to spend least amount of time on just trying to get stuff working, and most people in offline game jams do use unity. I wonder if it’s possible to use unity’s html5 target and somehow use nwjs or other web technologies to get it working. I see some posts use Unity’s android target and install a layer of android on Raspberry Pis to get unity working, but that just seem too messy.

5

I managed to build amulet on GameShell, but it crashes when running. Is it possible to see the log? Putting &>error.log in the meny load script doesn’t work (file created, nothing written)

7

Explored building Amulet a little, quickly discovered the way it builds doesn’t work very well for us to make it work easily for the GameShell (Repository includes prebuilt files for SDL which is one of the reasons why you may not be able to actually link against the build when you try to compile Amulet)

It also seems to have problems compiling with an -m32 flag, so I wound up editing the Common.mk file here, albeit in a slightly dirty way.

snippet
snippet.png1269×261 40.2 KB

I thought I’d compile under Clang here and include some flags to optimize under this specific hardware. Next, I made sure I had tried to compile once, after which I would copy over libSDL2.a from /usr/lib/arm-linux-gnueabihfonto the build folder’s /lib where it replaces the included libsdl.a.

and then, after about an hour of playing around, got the right amount of linkflags to get Amulet to build.
make XLDFLAGS+="-lpthread -ldl -lXi -lasound -lsndio -lpulse -lwayland-egl -lwayland-client -lwayland-cursor -lX11 -lXext -lXxf86vm -lXrandr -lXinerama -lXcursor -lXss -lxkbfile -lxkbcommon -lSDL2"

I haven’t tested it beyond this, but it does ask for main.lua. If you’d like, I could probably send you the build.

Also, I’d probably suggest filing an issue towards their repo to add a linuxarmv7 target or something, so all of THIS would be reduced down to uh.
make TARGET=linuxarmv7

EDIT: Welp, turns out I’m having a segfault here. I’d test this with GDB and see what’s going on, but there’s no packages for this in the default repos. I guess this is a bit of a deadend? I’ll try to compile under a different Lua interpreter.

1 Like
8

Thanks for putting work into this!

Yeah I got segfault here too when trying to create a window. GDB gives me this:

Thread 8 "SDLAudioP2" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb06ff450 (LWP 17915)]
0x0053345c in ALSA_PlayDevice (this=0x84eec8)
    at /home/cpi/misc/amulet/third_party/SDL2-2.0.9/src/audio/alsa/SDL_alsa_audio.c:348
348        const Uint8 *sample_buf = (const Uint8 *) this->hidden->mixbuf;
(gdb) backtrace
#0  0x0053345c in ALSA_PlayDevice (this=0x84eec8)
    at /home/cpi/misc/amulet/third_party/SDL2-2.0.9/src/audio/alsa/SDL_alsa_audio.c:348
#1  0x004f0680 in SDL_RunAudio (devicep=0x84eec8)
    at /home/cpi/misc/amulet/third_party/SDL2-2.0.9/src/audio/SDL_audio.c:765
#2  0x004c2c16 in SDL_RunThread (data=0x84efe0)
    at /home/cpi/misc/amulet/third_party/SDL2-2.0.9/src/thread/SDL_thread.c:283
#3  0x004e6fea in RunThread (data=0x84efe0)
    at /home/cpi/misc/amulet/third_party/SDL2-2.0.9/src/thread/pthread/SDL_systhread.c:78
#4  0xb6db15d8 in start_thread (arg=0x0) at pthread_create.c:458
#5  0xb6d526fa in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76
   from /lib/arm-linux-gnueabihf/libc.so.6

Not sure where to go from here. I asked the developer and he doesn’t know what to do either. I don’t have any experience with gdb before and I don’t know what more can I get out of debugging. And I’m not sure if it’s an SDL issue or an Amulet issue (love2d audio is working well for me, but not sure if they’re using SDL audio or not)