[raiguard/Sanqui][2.0.7] Linux version requires GLIBC 2.30 and, thus, not working on 18.04 Ubuntu

[ShyLion]

18.04 Ubuntu and others Linuxes, based on it, does not have this version of glibc

[ShyLion]

Code: Select all

$ ldd --version | head -n1
ldd (Ubuntu GLIBC 2.27-3ubuntu1.6) 2.27

[raiguard]

We are aware of this. We attempted to downgrade the distro that our deployment servers target, but we ran into some problems and weren't able to resolve them before the release.

In the meantime, I recommend updating your distro. Ubuntu 18.04 went end of life last year.

[TOGoS]

Are you not using that magic downgrade-my-dependencies header that Wheybags invented? I was under the impression that this sort of solved the problem 'once and for all' (without resorting to using Docker images of old distros for compilation, which is what I had been doing before that).

It's a little sad/ironic that my "factorio build server" can no longer run the latest Factorio.

[raiguard]

I had no idea that this thing existed! We are not using it.

I would rather avoid resorting to magic, but I'll ask Sanqui about it.

[Sanqui]

To my knowledge it was never finished, and in fact, when prompted about it at the LAN party two months ago, Wheybags recommended against using it. I think there are still a few other tools promising to solve this though...

[TOGoS]

Darn! I wonder why he recommended against it. The concept seems straightforward enough. I have not actually tried it myself, though.

I suppose 'magic' was the wrong word. I'm usually against anything that obfuscates what's going on. The header just explicitly indicates the version of every function that it needs instead of leaving it up to the whims of the environment it was compiled on.

[Aeppo]

Hello,
Is there reason why you can't statically link with libm to prevent injecting dependency?
It is sliightly inconvinient if one updates his factorio to 2.0 as prompted and then it does not launch anymore..

[TOGoS]

I've also tried running the factoriotools/factorio:2.0.14 Docker image, which doesn't have the glibc problem, but does end up crashing after printing:

Code: Select all

+ runuser -u factorio -g factorio -- /opt/factorio/bin/x64/factorio --create /factorio/saves/_autosave1.zip --map-gen-settings /factorio/config/map-gen-settings.json --map-settings /factorio/config/map-settings.json
   0.000 2024-11-05 02:46:35; Factorio 2.0.14 (build 79988, linux64, headless, space-age)
   0.000 Operating system: Linux
   0.000 Program arguments: "/opt/factorio/bin/x64/factorio" "--create" "/factorio/saves/_autosave1.zip" "--map-gen-settings" "/factorio/config/map-gen-settings.json" "--map-settings" "/factorio/config/map-settings.json"
   0.000 Config path: /opt/factorio/config/config.ini
   0.000 Read data path: /opt/factorio/data
   0.000 Write data path: /factorio [15841/95367MB]
   0.000 Binaries path: /opt/factorio/bin
   0.001 Error Util.cpp:81: Operation not permitted

The permissions on the directories all seem cromulent. The problem seems to be Factorio itself (which is why I'm mentioning it, here) failing to do something, but we don't know what.

Anybody want to add a better error message?

(I'd take a stab at it myself if I still had source access. )

[Aeppo]

Maybe running it under strace will at least show you which syscall failed?

[vadcx]

Same story on AlmaLinux 8 for a dedicated server (still on security-only support like LTS): https://endoflife.date/almalinux

I wrote a draft of what we came up with, feedback and improvements appreciated. It took so much time, I lost the desire to play but I can confirm the server starts and generates a fresh map with only the latest glibc replaced. https://wiki.factorio.com/User:Vadcx/Li ... bc_version This was discussed on the forums before, those links are included too.