ZDoom

Hi, i have an issue where GZDoom doesn't even start up, i just get the following error message: Script error, "gzdoom.pk3:compatibilty.txt" line 6: SC_GetFloat: Bad numeric constant "1.090909"

If it helps, i'm running Canaima 4.1 (Basically a rebrand of Linux Mint Debian Edition with crappy added apps), the GZDoom is 3.3.2 installed from the .deb packages stored in the ZDoom.org archive.
The only specifications of this PC i know of are a 1.4GHz Celeron CPU, some Intel iGPU i don't know the name of and 2GB of RAM.

I already tried extracting the gzdoom.pk3 and zd_extra.pk3 from the latest .zip distribution of GZDoom and that doesn't fix anything, same after a reinstall.

What’s your system language? Execute locale command in Terminal and post its output.

Sorry for the very late reply, but the output is the following:
https://pastebin.com/dUT7ASSm

So, i assume that changing the language to english will fix this?

Yes, this may help because it's something with conversion from string to numbers.
We do some explicit things in code to make such conversion language agnostic. Apparently this fails for unknown reason in your case.

The relevant comment says:

// Set LC_NUMERIC environment variable in case some library decides to
// clear the setlocale call at least this will be correct.
// Note that the LANG environment variable is overridden by LC_*

So apparently some component the app links to on your system is playing foul here.
(BTW, am I the only one who thinks that it's borderline [censored word] to implement this so that the internal workings of the entire CRT can be affected globally by this?)

Me too. Until this issue I didn’t even know that we have a dependency on locale settings.
There is a non-standard set of functions in some C library implementations that accepts locale explicitly as an argument.

We always had that dependency. Which is all fine and well if the same CRT wasn't shared with any system library the app pulls in directly or indirectly. You only need to have one stinker in there which doesn't handle this properly and all hell will break loose.

What I don't get is that they just altered the behavior of the standard parsing/text output functions instead of providing separate locale-aware versions. That entire attitude is just playing with fire and risking to break stuff. It's amazing that it took this long for this problem to show under Linux. Fortunately, on Windows this is impossible because the statically linked CRT is not shared with anything. No idea about Mac, though.