Bug #1351

Flatpak of ET:Legacy

Added by Eonfge 4 months ago. Updated about 1 month ago.

Status:Fixed% Done:

100%

Priority:NormalSpent time:-
Assignee:-
Category:Client
Target version:ALL
OS:Linux Arch:64-bit

Description

Over at Flathub.org, there is a small project going on to get all classic Id titles packaged for Flatpak. Multiple Doom-engines has been released, Quake 1 and 2 are in review, and I’ve been working on RTCW and ET:L
https://github.com/flathub/flathub/issues/1160

ET:Legacy is almost completely working, which would mean that it could become available for all Linux users on all distributions. There is only one thing holding the distribution back. I get a segmentation fault on start-up, and I’m not skilled enough in C and the fine workings of ET:L to get this sorted.

So really, I’m just asking here upstream if anybody could look into the cause of this crash. It might be something minor that we could easily fix in the Flatpak, but it would mean that the path is clear for publishing ET:Legacy to a wide variety of Linux distributions.

Current development branch were I’m working on:
https://github.com/Eonfge/flathub/tree/com.etlegacy.ETL
If you clone it and run the shell script, things should guide themselves from there.

strace.log - Last bit of the crash (7.44 KB) Eonfge, 25.09.2019 17:20

Associated revisions

Revision 6dbde6c4
Added by ryven 3 months ago

general: fix engine crash on 64bit systems, refs #1351 #1211 #1089

Engine was crashing on startup on 64 bit systems on Release builds.

It was happening due to SSE optimizations taking place, yielded by the
compiler on default settings (ETLegacy does not specify any optimization
flags by default). Most specifically the "movaps" instruction was failing
because it could not null several structure fields (in token_t) at once,
because it could not operate properly on Z_Malloc’ed memory block, as the
instruction requires a 16 byte boundary alignments, where Z_Malloc only does
4/8 byte paddings (depending on the system). The token_t alignment was 16 byte
due to the usage of "long double" type on "floatvalue" field, which is
extraordinarily big, even though on the 32bit systems it still occupies
12bytes, the struct alignment stays within 4 bytes, because the type is
non-atomic. The token_t "floatvalue" and "intvalue" now matching the
"pc_token_t" field types, as this makes more sense, since "pc_token_t" is the
structure used to receive "token_t" values on the mod side.

  • fixed botlib token_t alignment, was breaking sse optimization (causing
    the crash)
  • shut some botlib warnings

History

#1 Updated by ryven 4 months ago

`-DCROSS_COMPILE32=0`
Unfortunately there is a bug that we still haven’t figured out yet, that prevents 64 bit release to be built properly, however, 32 bit version should work fine.

ref https://dev.etlegacy.com/issues/1211

Moreover, i wouldn’t suggest packing 64bit version anyways, since mostly mods are built for 32bit arch.

#2 Updated by Eonfge 4 months ago

ryven wrote:

`-DCROSS_COMPILE32=0`
Unfortunately there is a bug that we still haven’t figured out yet, that prevents 64 bit release to be built properly, however, 32 bit version should work fine.

ref https://dev.etlegacy.com/issues/1211

Moreover, i wouldn’t suggest packing 64bit version anyways, since mostly mods are built for 32bit arch.

That will put us in a fairly unique position on Flathub. Only Steam and Lutris have 32bit support at the moment, but I do see your concern in regards to 32bit mods. I’ve little sympathy to closed source 32bit mods, but if 32bit is the only thing that compiles, then I’ll take it

#3 Updated by Spyhawk 3 months ago

  • Target version changed from N/A to ALL

#4 Updated by ryven about 1 month ago

  • % Done changed from 0 to 100

This should be fixed now.

#5 Updated by ryven about 1 month ago

  • Tracker changed from Feature to Bug
  • Status changed from New to Fixed

Also available in: Atom PDF