TC & FL crash, AP works? - Linux Fedora 42

[strangeloop]

Through steam I can launch and have been playing AP with no trouble, the other two (TC and FL) both crash immediately when launching.

I have found two issues:
1. When launching .X3FL_config (or X3AP_config or X3TC_config for that matter) from the command line it fails to find libjpeg.so.8

Code: Select all

OK jv@spire:X3 Terran Conflict$ ./X3FL_config
./X3FL_config: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

ldd confirms the library is not found: libjpeg.so.8 => not found
I can force it to look in the lib directory to circumvent that, which leads to a seg fault.

Code: Select all

ERR [1]  jv@spire:X3 Terran Conflict$ LD_LIBRARY_PATH=lib ./X3FL_config
Segmentation fault (core dumped)

2. There seems to be either a race condition with TC and FL that doesn't exist in AP that is circumvented by slowing initialization down with strace/gdb, or those programs are loading libs into the environment that the games need, potentially older 32-bit variants. This allows me to launch and play both TC and FL.

Code: Select all

export LD_LIBRARY_PATH="$PWD/lib"
strace -e trace=none ./X3FL_config

My suspicion is that as a result of running Fedora 42 my libraries are too recent and incompatible with the executables, but I don't know why AP would work via steam with no need to jump through the command line hoops.

[strangeloop]

This is what I'm doing to work around the issue at present but it is not ideal. I wanted to add it for anyone else running into the issue in case they wanted to just play the game at any cost.

You probably don't need the nvidia lines, that's only there because I have 2 graphics cards and I want to force X3 to use my render card.

Code: Select all

#!/bin/bash
export LD_LIBRARY_PATH="$PWD/lib"
export __NV_PRIME_RENDER_OFFLOAD=1
export __GLX_VENDOR_LIBRARY_NAME=nvidia
gdb -ex run --args ./X3FL_config

[strangeloop]

Well, I updated some packages today and now it's broken.

Code: Select all

L lib: (EE) ALCpulsePlayback_contextStateCallback: Received context failure!
AL lib: (EE) ALCpulsePlayback_connectStream: Stream did not get ready: Protocol error
======================================
!context
======================================

Looks like a compat issue between OpenAL and pulse. I am using pipewire-pulse.

Code: Select all

● pipewire-pulse.service - PipeWire PulseAudio
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service

I'm thinking there isn't enough separation between the game libraries and the system libraries, that's a hard thing to get right in linux because of how fast things can rev. My sympathies to the devs trying to make linux happen.

BTW It's not just X3 that broke today as a result, games that previously worked in wine no longer have sound.

[strangeloop]

lol back again with another hack, adding here in case it works for someone in the future

Code: Select all

#!/bin/bash
export LD_LIBRARY_PATH="$PWD/lib"  # help the game find that libjpeg.so...?
export __NV_PRIME_RENDER_OFFLOAD=1  # you probably dont need this
export __GLX_VENDOR_LIBRARY_NAME=nvidia # you probably dont need this
export ALSOFT_DRIVERS=alsa # this is the new line, forcing alsa circumvents the latest pipewire-pulse issue
gdb -ex run --args ./X3FL_config # no idea why this works, still think it has something to do with loading libs or stubbing functions that are missing

[PGeyer-Ego]

Hello strangeloop,

Thank you for this report.
I can look into it and see if I can get a proper fix for it.

As you've probably deduced, you do not need to run X3*_config but can just run X3*_main and that should circumvent your libjpeg issue. Obviously this isn't ideal as the config executable is still needed for... changing the config, but may help your temporary solution have a few less hacks.
X3 was written expecting ALSA devices. If it cannot find an ALSA device, then unfortunately the current behaviour is that it crashes, which is obviously not particularly ideal.

Thanks
PG

[strangeloop]

Awesome thanks for the reply! Let me know if you need help with testing a fix should it ever come to fruition. I'm playing via gdb for now and it seems to work