Author Topic: Problem starting fs2_open (wrong libgl)  (Read 2388 times)

0 Members and 1 Guest are viewing this topic.

Problem starting fs2_open (wrong libgl)

yesterday, I tried to start fs2_open after a longer period (months) and it won't start anymore. I have a new PC, but the configuration (kernel, drivers etc) is still the same.
It seems that SDL (or fs2 itself) is trying to load DRI libgl (swrast), which fails.

Code: [Select]
export LIBGL_DEBUG=verbose
Future debug output directed to: /home/maniac/.fs2_open/data/fs2_open.log
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib64/dri/tls/
libGL: OpenDriver: trying /usr/lib64/dri/
ATTENTION: default value of option force_s3tc_enable overridden by environment.
libGL: Can't open configuration file /home/maniac/.drirc: No such file or directory.
libGL: Can't open configuration file /home/maniac/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  32
  Current serial number in output stream:  33
I even tried an old 3.7.1 executable that still was present, but that stopped with the same error.

Video card in fs2_open.ini
Code: [Select]
VideocardFs2open=OGL -(1920x1080)x32 bit
I already tried disabling drm in the kernel (and recompiling nvidia-drivers), but that didn't help. Other games and 3D-Applications still run well.

Video card: nVidia GeForce GTX 960
Driver: nVidia 358.16
Linux-Kernel: 4.3.3

Any ideas what I could try? Can I specify the correct GL driver in fs2_open.ini and if yes, how can I see what name to choose?

Thanks for any replies in advance

[attachment DELETED!! by Strong Bad]

Re: Problem starting fs2_open (wrong libgl)
Okay... After some more googling I tried adding my nvidia lib-path to LD_LIBRARY_PATH and this helped. Well... LD_LIBRARY_PATH was completely empty before...
I wonder how that worked for so many years. I'll look into my compile options a bit.