GodotSteam: Does not support GLIBCXX_3.4.28, the latest available on many LTS Linux systems

Describe the bug I downloaded GodotSteam via both the Godot Asset Library, and as an independent build. In both cases, switching back to the editor consistently gives me a “Load Errors” window, stating “Error loading extension: res://addons/godotsteam/godotsteam.gdextension”. Closing this window and moving to output, I get this more detailed explanation:

Can't open dynamic library: /home/michael/Documents/Godot/FPSDoodad/addons/godotsteam/linux/libgodotsteam.debug.so. Error: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /home/michael/Documents/Godot/FPSDoodad/addons/godotsteam/linux/libgodotsteam.debug.so)
  core/extension/gdextension.cpp:400 - GDExtension dynamic library not found: /home/michael/Documents/Godot/FPSDoodad/addons/godotsteam/linux/libgodotsteam.debug.so
  Failed loading resource: res://addons/godotsteam/godotsteam.gdextension. Make sure resources have been imported by opening the project in the editor at least once.

This implies that I need GLIBCXX_3.4.29 to use it, but my operating system, Linux Mint 20.3 (an LTS through 2025), only supports up to GLIBCXX_3.4.28. I am having a terrible time trying to find a method, of minimal possible damage, for getting 3.4.29 running on my machine. Most of it is coming back to upgrading to a newer version, which will take some time and, according to Mint Upgrade, will probably impede a number of other elements I’ve installed since getting 20.3 LTS on here…

I’m more a multimedia guy than a systems engineer, so I feel like this may qualify as a bug? If not, and anyone is willing to push me in the right direction, it would be enormously appreciated.

To Reproduce Steps to reproduce the behavior:

  1. Download Godot 4.02 on any Ubuntu Focal-based OS supporting less than 3.4.29 out of the box.
  2. Start a new project, and install GodotSteam from the Asset Library. Alternatively, download the build and run it.
  3. Note the above errors appearing.

Expected behavior In an ideal world, downloading the GDExtension would be enough to get it going. I think that’s the general idea. (Also I would be able to continue on this highly customized OS until 2025, like I was humbly hoping…)

Screenshots image image

Desktop (please complete the following information):

  • OS: Linux Mint
  • 20.3 Una

Version of Godot: Godot 4.0/4.01/4.02

Version of GodotSteam: 4.2.3, GDExtension, pre-built binary

Additional context Again, I apologize if I’m simply ignorant of the C++ library system; most of my work is in animation and it really doesn’t come up often. However, I’m not entirely ignorant and I’ve successfully compiled Godot itself from C++, on this same system, with no issues; so this seems a little anomalous to me and worth bringing up.

Is it possible to build GodotSteam with an earlier dependency?

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 31 (15 by maintainers)

Most upvoted comments

Replacing libgodotsteam.debug.so with that file (and file name) has ceased warning me about failing to load the extension, which is great! I’ll need to come back to it later to ensure that all behavior is as expected from, say, a tutorial; but things are looking good.

This was tested, if it matters, on 4.0.2. Expect to hear from me again later, after I’ve woken up a little… ☕

I’ve gone through the entire tutorial and it all works great. Thanks for taking care of that!

I’m a little short of fifteen minutes into the Dawn’s Crow tutorial on the lobby system with GodotSteam, on YouTube; so far, it can connect to Steam, knows my Steam Name, and everything is working great. Also I can create a lobby. Other than being on the default asset library, I’d say this is pretty settled!

Awesome, let me know if it works! And welcome! And thank you for letting me know about this issue.

./libgodotsteam.linux.template_debug.x86_64.so:
	linux-vdso.so.1 (0x00007ffeabbff000)
	libsteam_api.so => not found
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5257419000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f52572ca000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f52572af000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f52570bd000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5257b7d000)

	Version information:
	./libgodotsteam.linux.template_debug.x86_64.so:
		libgcc_s.so.1 (GCC_3.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
		libstdc++.so.6 (CXXABI_1.3.8) => /lib/x86_64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.18) => /lib/x86_64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3.9) => /lib/x86_64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (CXXABI_1.3) => /lib/x86_64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.15) => /lib/x86_64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4) => /lib/x86_64-linux-gnu/libstdc++.so.6
		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libstdc++.so.6:
		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		libgcc_s.so.1 (GCC_4.2.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.4) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.3) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.6) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.18) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libm.so.6:
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libgcc_s.so.1:
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libc.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
./libgodotsteam.linux.template_debug.x86_64.zip:
	not a dynamic executable

…Looking good! I’ll try it out tomorrow when I’m working again. Thank you so much!

Can confirm that it still requires 3.4.29.

Hmm, no matter what I try this never seems to affect the output. That being said, I will attempt to reinstall a VM copy of 16.04 and build a version to compare. Here is the last test that most likely failed: libgodotsteam.linux.template_debug.x86_64.zip

Or maybe it did—did you send the right link to the right version? Diff is telling me that the two files (official asset repo, and the zipped one) don’t differ at all.

@MichaelMacha Can you test out these replacements? Using the Linux SDK that @Trey2k suggested. libgodotsteam.zip

Checking with ldd -v seems to say this is probably fixed; unless I’m reading it wrong which is always possible. I went ahead and applied this process to the GDNative version which is most likely suffering from the same issue. We are looking at adding the buildroot stuff to our Github Actions for GDNative and GDExtension. Thanks @Trey2k!

Hey there! Hmm, yes, libc - the eternal problem. Haha. I had built the Linux components on Ubuntu 20.04 and failed to remember to check what version of libc was installed. Ideally I -should- be using 18.04 or, better yet, 16.04 to do this for the best compatibility. I was worried about creating a Github Actions for the plug-ins since Github decided to depreciate all their pre-20.04 runners for whatever reason.

I will swap back over to my Linux environment to double-check what I was using, but I’m gonna guess I need to reinstall my VM of 16.04 and make versions in there; which isn’t a big deal.

Thank you for reporting this! Definitely a big issue that should be fixed soon.

You could always use https://github.com/godotengine/buildroot

Hey there! Hmm, yes, libc - the eternal problem. Haha. I had built the Linux components on Ubuntu 20.04 and failed to remember to check what version of libc was installed. Ideally I -should- be using 18.04 or, better yet, 16.04 to do this for the best compatibility. I was worried about creating a Github Actions for the plug-ins since Github decided to depreciate all their pre-20.04 runners for whatever reason.

I will swap back over to my Linux environment to double-check what I was using, but I’m gonna guess I need to reinstall my VM of 16.04 and make versions in there; which isn’t a big deal.

Thank you for reporting this! Definitely a big issue that should be fixed soon.