majesty: segfault on start

[kujeger]

Hello, first of all -- thanks for all the great work!

The linux port of Majesty from the now defunct Linux Game Publishing segfaults on start with sdl12-compat.

Using real SDL-1.2 from the system, along with some other system-replacements for various bundled libraries, works well.

A demo can be grabbed from http://demos.linuxgamepublishing.com/

Tested on Fedora 37 beta, SDL2.24, sdl12-compat 1.56 and 1.58

Possibly somewhat useful gdb bt

[sulix]

I tried this out, and I can reproduce the same issue here (albeit with the Intel iris driver), and I don't think it's a direct issue with sdl12-compat, but just an old binary which conflicts with the C++ use in the Mesa stack.

See the related issues:

• https://bugs.freedesktop.org/show_bug.cgi?id=108933
• https://gitlab.freedesktop.org/mesa/mesa/-/issues/1924

The usual tricks, like LD_PRELOADing libstdc++.so.6 will often give a slightly different error. It looks like the maj_demo binary exports its own __dynamic_cast, so it probably has a statically-linked libstdc++, which sets up some global state in an incompatible way when loaded, or something.

That being said, the game seems to run, and work okay, when run with the nVidia driver, which doesn't use libstdc++.

It also works when using SDL_RENDER_DRIVER=software SDL_FRAMEBUFFER_ACCELERATION=false, even with the Intel/Mesa/iris driver.

(The map scrolling is too fast, but otherwise it seems to work pretty well.)

[kujeger]

Thanks! Can confirm that it works here as well with SDL_RENDER_DRIVER=software SDL_FRAMEBUFFER_ACCELERATION=false on radeon.

[sezero]

Runs fine here without any special environment vars set, but this is an old setup..

[icculus]

Should we close this?

[kujeger]

Looks like it to me!

Should I ever manage to work around the mesa/libstdc issue and discover any problems with sdl12-compat I can create a new issue.

[slouken]

Do we want to add a hint for the software renderer for this title?

[icculus]

Do we want to add a hint for the software renderer for this title?

I guess it couldn't hurt. The way we did this for Civ:CTP was to actually patch the game binary to call into a little stub library that provides these things in a more-compatible way, making it not our problem, but it's possible Civ needed that beyond just rendering, or the issue was different in general.

Out of curiosity, does anyone know if we're in the same boat for a hypothetical Vulkan renderer, or does the C++ issue die with Mesa's OpenGL implementation?

[icculus]

The demo binary is called maj_demo; can someone confirm the name of the retail binary? I need it for the quirks table.

[kujeger]

Full game binaries are majesty and majx.

I wonder if using Zink for opengl-over-vulkan would change anything?

[icculus]

Weirdly, this game works with OpenGL for me on Mesa:

OpenGL renderer string: Mesa Intel(R) UHD Graphics (CML GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.0.5

Ubuntu 22.04.

I do worry that, even though the game is software-rendered, there's going to be some pain in trying to scale this up to a 4K display with SDL's software renderer that we can avoid if the GPU can handle that effort.

[slouken]

Good point.

[icculus]

Okay, I think I'm going to leave this alone in sdl12-compat, since the LGP and Loki games need a lot of tender loving care to run regardless of which SDL implementation one uses, and the old-libstdc++/Mesa conflict would fall into that realm.