$ ./GOG\ Games/Eschalon\ Book\ I/start.sh
Running Eschalon: Book I
support/gog_com.shlib: line 134: 25788 Segmentation fault (core dumped) ./aoss ./"${bin_64}"

$ ./GOG\ Games/Eschalon\ Book\ I/game/Eschalon\ Book\ I
[1] 25850 segmentation fault (core dumped) ./GOG\ Games/Eschalon\ Book\ I/game/Eschalon\ Book\ I

$ ./GOG\ Games/Eschalon\ Book\ II/start.sh
Running Eschalon: Book II
./start.sh: line 16: 24887 Segmentation fault (core dumped) ./"eschalon_book_2"

$ ./GOG\ Games/Eschalon\ Book\ III/start.sh
Running Eschalon: Book III
./GOG Games/Eschalon Book III/start.sh: line 16: 26348 Segmentation fault (core dumped) ./"eschalon_book_3"

This is on the unsupported Arch Linux, does anyone experience the same or has found a solution?

The games used to work for me, but some time in the last few years they started crashing as well (I use gentoo, and way too much changes all the time for me to figure out the root cause). I tried to trace the issue with gdb and compiling various libraries with debugging libraries, but every time I made a slight change it just crashed in a different place. I then decided it wasn't worth the effort, and switched to the Windows versions (via wine). The only issue with wine is that you have to guess the location of the start button on book 1 (and probably also the renderer, but that can also be edited via cfg).

Thanks. The weird thing is that a friend uses Manjaro (so practically also Arch) and it works for him. The only major difference we could find so far is that he uses Nvidia and I AMDGPU. All the debug info I found also looked like it might be OpenGL related.
I played Book II today in wine and it worked fine. I still wish it worked natively.
Thanks for your help.

Just chiming in to say I have found the same issue on Arch Linux with an AMD card.

I believe I have finally tracked down the problem. At some point, gcc changed its default 32-bit ABI from 4-byte aligned stacks to 16-byte aligned stacks. When you compile with this recent gcc, your libraries will assume that multimedia instructions that require 16-byte stack alignment will not fail, but because the older code uses 4-byte alignment, they do. If you look at your crash in gdb, and the instruction that failed has one of the xmm* registers in it, that's the problem.

I have verified this by creating an LD_PRELOAD shim that receives arguments with 4-byte alignment and passes them on with 16-byte alignment. At first I added all the functions where Eschalon crashed, and, when I lost track of it (all ??? from gdb), I added all GLX and GL calls it used. With that, the game appears to work. I haven't done much testing, but I can create a character and run around a bit. The other two games don't use any additional GLX/GL calls, so the shim should work with them as well (I can at least start both of them without issue).

You can obtain my fix from my github account if you want to try it yourself. For your convenience, I have uploaded the compiled binary that I use to the "release" section. Simply add it to your LD_PRELOAD environment variable. For example, add "export LD_PRELOAD=stack-fix.so" to run_game() in start.sh if that's how you launch the game.

This issue probably affects other old 32-bit games, as well.

The best solution would be for Basilisk to recompile with a more recent gcc (or setting the default alignment options to 16-byte manually). However, I don't like having to contact the developers directly, and don't feel like bugging gog support, either, so I guess that won't happen.

The second best solution is to generate a shim as I did above, but with even more automation. It would've been nice to just generate assembly jump instructions, but the shim needs to know the length of the argument list, so it can shift them upwards if the stack needs to be realigned. As is, the above shim may not be perfect. If you find more reproducible crashes, file an issue on my github page and I'll look into it.

The third-best solution would be to recompile all the libraries the game uses that might be affected. Probalby xcb and GL, at least. This might have a trivial effect on performance of every other program that uses these libraries, and also require a bit of effort, but would otherwise be safe

[edit 4: rewrote for clarity and typo removal; also added binary download]
[edit 5: I moved (back) to github, so I replaced all bitbucket references]

In case anybody's still interested, subj works out of the box on Ubuntu 20.04
At least the version downloaded directly from the dev's website.

PS And on Fedora 25 as well