Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on Manjaro Arm64 #3269

Closed
coreybruce opened this issue Oct 7, 2023 · 24 comments
Closed

Crash on Manjaro Arm64 #3269

coreybruce opened this issue Oct 7, 2023 · 24 comments

Comments

@coreybruce
Copy link

coreybruce commented Oct 7, 2023

Hey there, I successfully got Shipwright compiled on my Raspberry pi on Manjaro Arm64 but when I try and run Shipwright it says it crashed and I was wondering/hoping this could be fixed/resolved so we can enjoy this on the pi4 and even the 5 in the future.

Log: Ship of Harkinian.log

@Malkierian
Copy link
Contributor

Looks like it's something about OpenGL 3. The Pis use OpenGL ES, which can be significantly different from normal OGL. You'd have to add ES as a backend for LUS. The Android port also had to deal with this, you might look into that to get the build running, but if that gets upstreamed you might not actually have to do that work yourself later on. https://github.com/Waterdish/Shipwright-Android

@Malkierian
Copy link
Contributor

Sorry, this would probably be more applicable https://github.com/Waterdish/libultraship

@jschwartzenberg
Copy link

It seems I have a similar issue. This is with an Intel GM45:

[2024-01-02 17:50:59.669] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:452] [info] Opened mpq file /home/julius/games/oot-mq.otr.
[2024-01-02 17:50:59.798] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:485] [info] (/home/julius/games/oot.otr) Patched in mpq file.
[2024-01-02 17:50:59.833] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:518] [info] (/tmp/.mount_soh.apRygoy7/usr/bin/soh.otr) Missing version file. Attempting to apply patch anyway.
[2024-01-02 17:50:59.833] [/home/runner/work/Shipwright/Shipwright/libultraship/src/resource/Archive.cpp:485] [info] (/tmp/.mount_soh.apRygoy7/usr/bin/soh.otr) Patched in mpq file.
Failed to initialize OpenGL loader!
[2024-01-02 17:51:01.163] [/home/runner/work/Shipwright/Shipwright/libultraship/src/public/libultra/os.cpp:20] [info] Added SDL game controllers from "/tmp/.mount_soh.apRygoy7/usr/bin/gamecontrollerdb.txt" (287)
[2024-01-02 17:51:03.865] [/home/runner/work/Shipwright/Shipwright/libultraship/src/debug/CrashHandler.cpp:72] [critical] Signal: 11
INVALID ACCESS TO STORAGE
Registers:
RAX: 0x0000000000000000
RDI: 0x000055BCA99D8290
RSI: 0x000055BCA99D82A0
RDX: 0x000055BCA99D09C0
RCX: 0x0000000000000003
R8:  0x00007FFC2952E270
R9:  0x0000000000000000
R10: 0x000055BCA7115DE0
R11: 0x00007F5770F07500
RSP: 0x00007FFC2952E2A0
RBX: 0x000055BCA9A07340
RBP: 0x00007FFC2952E330
R12: 0x000055BCA9A07340
R13: 0x00007FFC2952E360
R14: 0x00007FFC2952E320
R15: 0x00007FFC2952E310
RIP: 0x000055BCA70B05E2
EFL: 0x0000000000010202
Traceback:
1 /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f5770f50420]
2 ImGui_ImplOpenGL3_NewFrame() (+0x22)
3 LUS::Gui::DrawMenu() (+0xEF)
4 gfx_start_frame() (+0x7E)
5 Graph_StartFrame (+0x124)
6 ./soh.elf(+0x9197be) [0x55bca6b157be]
7 ./soh.elf(+0xd557fa) [0x55bca6f517fa]
8 Graph_ProcessFrame (+0x3B)
9 Main (+0x36B)
10 main (+0x2E)
11 __libc_start_main (+0xF3)
12 _start (+0x2E)
Build Information:
Game Version: Sulu Bravo (7.1.1)
Build Date: Aug 14 2023 00:46:21

It supports OpenGL 2.1 (and OpenGL ES 2.0) only. At least OpenGL 3.0 is required?

@gustavostuff
Copy link

gustavostuff commented Jan 31, 2024

It supports OpenGL 2.1 (and OpenGL ES 2.0) only. At least OpenGL 3.0 is required?

According to one of the devs, 3.1 is enough. The thing is, as mentioned already, the differences between normal vs ES implementations.

@jschwartzenberg
Copy link

jschwartzenberg commented Jan 31, 2024

3.1 is too much for quite a bit of hardware that did run the game in an emulator only supports OpenGL 2.1 and OpenGL ES 2.0.

Hopefully older OpenGL versions may also work at some point.

@Malkierian
Copy link
Contributor

Emulators have different requirements than SoH. SoH is a port, and has been somewhat reworked to take advantage of newer APIs. Support for less than 3.x likely will never happen because it now relies on some of those newer API functions.

@gustavostuff
Copy link

gustavostuff commented Jan 31, 2024

@Malkierian that makes sense. Hopefully devices like raspberry pi wil support newer versions of opengl in the future.

I was talking to a friend who compiled SoH inside a raspberry pi 4 (8GB) with RGB-Pi OS4. The issue seems to be the lack of Xorg, which makes sdl2 fail. This is probably a different issue tho.

Edit: @coreybruce if this ever happens, it may be useful for you.

@coreybruce
Copy link
Author

@Malkierian that makes sense. Hopefully devices like raspberry pi wil support newer versions of opengl in the future.

I was talking to a friend who compiled SoH inside a raspberry pi 4 (8GB) with RGB-Pi OS4. The issue seems to be the lack of Xorg, which makes sdl2 fail. This is probably a different issue tho.

Edit: @coreybruce if this ever happens, it may be useful for you.

Oh nah it has nothing to do with that issue but thank you for sharing, it seems like the pi 5 will be needed to play this since it supports OpenGL 3 and Vulkan

@retropieuser
Copy link

Just a quick note, pi5's VideoCore VII GPU supports OpenGL ES 3.1 apparently, so the OpenGL issues could be solvable on a Pi 5?

@fac3l3ss79
Copy link

fac3l3ss79 commented Feb 18, 2024

It does compile and run on a raspberry pi 5 with raspberry pi os 64 bit bookworm. Seems to run great except the screen to choose the save file, which slows down.

But has anyone managed to compile successfully on a pi 4 bullseye 32 bit? (I get a compiling error concerning RumbleMappingFactory.cpp, i think...)

@coreybruce
Copy link
Author

coreybruce commented Feb 18, 2024

Just a quick note, pi5's VideoCore VII GPU supports OpenGL ES 3.1 apparently, so the OpenGL issues could be solvable on a Pi 5?

Yeah I'm definitely going to test this out and get a pi 5 when I can 😁👍

@Malkierian
Copy link
Contributor

Malkierian commented Feb 18, 2024

But has anyone managed to compile successfully on a pi 4 bullseye 32 bit? (I get a compiling error concerning RumbleMappingFactory.cpp, i think...)

Like with 64-bit Pi, 32-bit anything is unsupported out of the box and requires extra changes to CMake to even attempt to build. What those changes are for 32-bit will have to be discovered or specified by someone else, and we have no official support for any of it.

@jschwartzenberg
Copy link

32-bit anything is unsupported out of the box and requires extra changes to CMake to even attempt to build. What those changes are for 32-bit will have to be discovered or specified by someone else, and we have no official support for any of it.

It's running on my ASUS Tinkerboard S, which has a 32-bit CPU: https://en.wikipedia.org/wiki/Rockchip_RK3288

@coreybruce
Copy link
Author

Actually I just found out the Raspberry pi 4 does have OpenGL 3.1 support back in 2020

https://www.hackster.io/news/raspberry-pi-4-model-b-gains-official-opengl-es-3-1-conformance-certification-from-the-khronos-group-0c5e7b31c625

Can we please re look at this issue?

@fac3l3ss79
Copy link

fac3l3ss79 commented Mar 31, 2024

Hi there! I now managed to compile and run sucessfully on a raspberry pi 4/400 with raspberry pi os 64 bit bullseye!
A newer version of libsdl2 and libsdl2-dev needs to be compiled and installed though (I used sdl2 2.26.5).
This is a must for soh to compile sucessfully on a raspberry pi 4 with 64 bit bullseye and run.
Here are the instructions for this:

sudo apt-get install -y libasound2-dev libudev-dev libibus-1.0-dev libdbus-1-dev fcitx-libs-dev libsndio-dev libx11-dev libxcursor-dev libxext-dev libxi-dev libxinerama-dev libxkbcommon-dev libxrandr-dev libxss-dev libxt-dev libxv-dev libxxf86vm-dev libegl1-mesa-dev libgles2-mesa-dev libgl1-mesa-dev libglu1-mesa-dev libdrm-dev libgbm-dev libfontconfig1-dev automake mercurial libtool libfreeimage-dev libopenal-dev libpango1.0-dev libsndfile1-dev libtiff5-dev libwebp-dev libaudio-dev freeglut3-dev libmodplug-dev libsmpeg-dev libjpeg-dev libsamplerate0-dev libjack-dev libopusfile-dev libmpg123-dev libfluidsynth-dev libvulkan-dev autoconf libvulkan-dev libvulkan1 libwayland-dev wayland-protocols

wget https://www.libsdl.org/release/SDL2-2.26.5.tar.gz && tar xf SDL2-2.26.5.tar.gz
cd SDL2-2.26.5
./autogen.sh
./configure --enable-video-opengl --disable-esd --enable-video-opengles --enable-libudev --enable-arm-simd --enable-video-vulkan --host=arm-raspberry-linux-gnueabihf
make -j4
sudo make install

You can also create deb packages and install. You will need to create a debian folder with changelog, control and other files (or you can copy/paste from https://www.libsdl.org/release/SDL2-2.0.18.tar.gz and make some changes) to create deb packages.
To this, use the following commands:
sudo apt-get build-dep libsdl2-2.0-0
dpkg-buildpackage -us -uc

then: sudo dpkg -i libsdl2-2.0-0_2.26.5_arm64.deb && sudo dpkg -i libsdl2-dev_2.26.5_arm64.deb

After this and following standard building instructions for linux, soh should compile.

Finally, package soh and run with:
MESA_GL_VERSION_OVERRIDE=3.1 MESA_GLSL_VERSION_OVERRIDE=300 ./soh.elf

Final note: libsdl2-dev needs to be installed, otherwise soh.elf will crash

@coreybruce
Copy link
Author

coreybruce commented Mar 31, 2024

Ah I forgot I was still having this issue which hasn't been resolved

#3780

EDIT: after getting some assistance on the Discord server I have now figured out the issue and I have given some feedback to add what is missing in the documentation

@coreybruce
Copy link
Author

coreybruce commented Mar 31, 2024

Hi there! I now managed to compile and run sucessfully on a raspberry pi 4/400 with raspberry pi os 64 bit bullseye! A newer version of libsdl2 and libsdl2-dev needs to be compiled and installed though (I used sdl2 2.26.5). This is a must for soh to compile sucessfully on a raspberry pi 4 with 64 bit bullseye and run. Here are the instructions for this:

sudo apt-get install -y libasound2-dev libudev-dev libibus-1.0-dev libdbus-1-dev fcitx-libs-dev libsndio-dev libx11-dev libxcursor-dev libxext-dev libxi-dev libxinerama-dev libxkbcommon-dev libxrandr-dev libxss-dev libxt-dev libxv-dev libxxf86vm-dev libegl1-mesa-dev libgles2-mesa-dev libgl1-mesa-dev libglu1-mesa-dev libdrm-dev libgbm-dev libfontconfig1-dev automake mercurial libtool libfreeimage-dev libopenal-dev libpango1.0-dev libsndfile1-dev libtiff5-dev libwebp-dev libaudio-dev freeglut3-dev libmodplug-dev libsmpeg-dev libjpeg-dev libsamplerate0-dev libjack-dev libopusfile-dev libmpg123-dev libfluidsynth-dev libvulkan-dev autoconf libvulkan-dev libvulkan1 libwayland-dev wayland-protocols

wget https://www.libsdl.org/release/SDL2-2.26.5.tar.gz && tar xf SDL2-2.26.5.tar.gz cd SDL2-2.26.5 ./autogen.sh ./configure --enable-video-opengl --disable-esd --enable-video-opengles --enable-libudev --enable-arm-simd --enable-video-vulkan --host=arm-raspberry-linux-gnueabihf make -j4 sudo make install

You can also create deb packages and install. You will need to create a debian folder with changelog, control and other files (or you can copy/paste from https://www.libsdl.org/release/SDL2-2.0.18.tar.gz and make some changes) to create deb packages. To this, use the following commands: sudo apt-get build-dep libsdl2-2.0-0 dpkg-buildpackage -us -uc

then: sudo dpkg -i libsdl2-2.0-0_2.26.5_arm64.deb && sudo dpkg -i libsdl2-dev_2.26.5_arm64.deb

After this and following standard building instructions for linux, soh should compile.

Finally, package soh and run with: MESA_GL_VERSION_OVERRIDE=3.1 MESA_GLSL_VERSION_OVERRIDE=300 ./soh.elf

Oh wow that is a really over complicated way with more work to compile it but I am happy for you haha

I just compiled it on Manjaro Arm64 and it was significantly easier to compile as the latest SDL2 is in the manjaro repos, I can now say that this issue is now completed

@fac3l3ss79
Copy link

fac3l3ss79 commented Mar 31, 2024

I just compiled it on Manjaro Arm64 and it was significantly easier to compile as the latest SDL2 is in the manjaro repos, I can now say that this issue is now completed

Be aware that libsdl2-dev needs to be installed, otherwise soh.elf will crash

@coreybruce
Copy link
Author

I just compiled it on Manjaro Arm64 and it was significantly easier to compile as the latest SDL2 is in the manjaro repos, I can now say that this issue is now completed

Be aware thar libsdl2-dev needs to be installed, otherwise soh.elf will crash

Yeah on manjaro it's just called sdl2 but that wasn't the issue originally, there was another issue that got resolved at some point upstream 😃

@bkacjios
Copy link

bkacjios commented Apr 15, 2024

Worth mentioning, but after Kenix3/libultraship@bd20dd4 I no longer get a crash when launching now on a Raspberry Pi 4 with archlinuxarm and aarch64 architecture. I found it was crashing for me since it was trying to use the x11 driver, despite me trying to run it in console. I guess getting rid of GLEW allows it to find the kmsdrv video mode and use that instead? Not entirely sure why.

But I also managed to get it working on 8.0.5 as well by overriding the SDL video driver like so..

SDL_VIDEODRIVER=kmsdrm soh

However, it still crashes for me when compiled for 32bit armv7h.

*** buffer overflow detected ***: terminated

(zenity:17854): Gtk-WARNING **: 19:00:28.920: Failed to open display

1 __default_rt_sa_restorer (+0x0)
2 /usr/lib/libc.so.6(+0x7e310) [0xb67be310]
3 raise (+0x20)
Build Information:
Game Version: MacReady Foxtrot (8.0.5)
Build Date: Apr 15 2024 21:40:39

@coreybruce
Copy link
Author

Worth mentioning, but after Kenix3/libultraship@bd20dd4 I no longer get a crash when launching now on a Raspberry Pi 4 with archlinuxarm and aarch64 architecture. I found it was crashing for me since it was trying to use the x11 driver, despite me trying to run it in console. I guess getting rid of GLEW allows it to find the kmsdrv video mode and use that instead? Not entirely sure why.

But I also managed to get it working on 8.0.5 as well by overriding the SDL video driver like so..

SDL_VIDEODRIVER=kmsdrm soh

However, it still crashes for me when compiled for 32bit armv7h.

*** buffer overflow detected ***: terminated

(zenity:17854): Gtk-WARNING **: 19:00:28.920: Failed to open display

1 __default_rt_sa_restorer (+0x0)
2 /usr/lib/libc.so.6(+0x7e310) [0xb67be310]
3 raise (+0x20)
Build Information:
Game Version: MacReady Foxtrot (8.0.5)
Build Date: Apr 15 2024 21:40:39

Yeah the issue has been resolved tho I think the game would be to much for a older Arm7l 32bit device, it stuttered/slows down on the pi 4 in the starting area but stable. Using a more powerful pi 5 gives better stability and performance

@briaguya-ai
Copy link
Contributor

briaguya-ai commented Dec 20, 2024

arm linux isn't an officially supported platform, but chances are if you stumbled across this issue you're looking for solutions not a "wontfix" - so i'll share what i know to hopefully point people in the right direction before closing this

a lot of the changes needed to get soh building on arm systems that don't have all the libs we'd expect on an x86_64 desktop needed to happen on the LUS side of things. relevant LUS PRs

there has been effort by the portmaster team to get soh running on arm linux handhelds

between that work and the fact that it seems the original reported issue has been resolved i'm going to close this thread, it seems the only unresolved crashes in this thread are 32 bit and the issue is titled arm64

@briaguya-ai briaguya-ai closed this as not planned Won't fix, can't repro, duplicate, stale Dec 20, 2024
@coreybruce
Copy link
Author

All tho it isn't officially supported I have already have been compiling it for Arm64 on a Arch based distros and redistributing for it as well as x64 and i686 with my AUR package

https://gitlab.com/linuxbombay/soh
https://aur.archlinux.org/packages/soh-bin

Thank you for all the hard work for getting it to work on Linux Arm64! I will continue to help support you guys by testing and reporting anything I can as well as compiling for it.

@jschwartzenberg
Copy link

It seems good to also highlight that while not officially supported, both aaarch64 (from what I'm reading here) and armhf (32-bit) are generally working fine. I found the game quite playable on my Tinkerboard S, which is using a 32-bit ARM chip which would already be considered relatively old I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants