Godot: [Compatibility] template glibc version check too strict

[Houkime]

Godot version:

3.2.dev.custom_build.ce8e54133

OS/device including version:

• Arch Linux - compiling machine
  
  
  
  • glibc 2.29
  
  
  • Scons 3.0.4
  
  
  • clang 8.0.0
  
  
• Ubuntu 18.04 - playing machine
  
  
  
  • glibc 2.27
  
  

Issue description:

Export templates compiled against glibc 2.29 won't run with glibc 2.27

Screenshot from ubuntu VM (replicating original issue):

Expected:

glibc check not that strict and considering actual ABI-breaking glibc changes and not just version numbers.

Steps to reproduce:

• compile Godot master on a machine with glibc 2.29 along with an x11 template.
  (probably 2.28 will also suffice)
• export any project using your compiled template
• try to run it on Ubuntu 18.04 (VM suffices) or probably any other system with glibc that differs from compile-time glibc.

Minimal reproduction project:
blank project should be enough (I used GLES3 3D scene)

[Houkime]

oops, actually used llvm this all time. Should check gcc as well.

[Houkime]

gcc-produced builds also demonstrate this behavior (gcc 9.1)

[Calinou]

If you want export templates to be portable across distributions, you should build them on the oldest distribution you wish to target. As of writing, using an Ubuntu 16.04 VM/container works well for this purpose. If you install a more recent GCC version using a PPA, you should pass the SCons flag use_static_cpp=yes so that the produced binary will work on older distributions.

It may also be possible to use glibc_version_header if you don't want to build on an older distribution, but there are no guarantees it will work well.

All in all, we don't have control over the glibc version checks. We should however document this more clearly in Compiling for X11.

[Houkime]

I tried use_static_cpp=yes now but it doesn't really help, at least with gcc.

Although it should and there is no point in it whatsoever if it doesn't since it means that linking was still dynamic despite this flag. Note that godot does not employ only C++, but C files also.

[Calinou]

Although it should and there is no point in it whatsoever if it doesn't since it means that linking was still dynamic despite this flag. Note that godot does not employ only C++, but C files also.

use_static_cpp=yes is only helpful if you use an old distribution with a recent compiler version. It won't help if you still build on a recent distribution.

[Houkime]

I ended up setting up a Debian 8 headless VM, building an x11 release template there with builtin libpng and extracting built binary via SFTP (which was as easy as forwarding an SSH port in virtualbox network settings).
Success though probably debian-based distros are not best for this (both on Debian and Ubuntu apt works _terribly_ slow compared to package managers in my other VMs ).
With Debian you can easily spend couple of hours installing a minimal headless server and then 30 min to up it to godot-building readiness. I can install Arch faster than that and it will even eat less memory))

[Calinou]

You could likely speed up the process a lot by setting up a Docker container:

docker run -it debian:8
# Starts an interactive session in the container
# (install dependencies then paste commands to build Godot here…)

To get the binary back on the local system, run these commands in another terminal window:

# Get the container name for use in `docker cp`
docker ps

# Copy the compiled binary to the local filesystem
docker cp <name>:/root/godot/bin/godot.x11.opt.64 .

You can reuse the container by starting it using docker start --attach <name>.

[akien-mga]

I thought we were building official Linux binaries on a recent Fedora, but @hpvb actually confirmed that we build them on an old Ubuntu release:

Official binaries are actually built on an ancient Ubuntu. There's no way at all to do this without that. The only option would be to start bundling a c library and libstdc++ with Godot...

So this issue effectively can't be solved. Documentation was improved in godotengine/godot-docs#2556 so this can be considered fixed. I might have a go at further improving the docs to document the use of use_static_cpp=yes, LTO and how to install a modern compiler on an ancient distro for best compatibility and performance.