Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: GNUser on March 30, 2025, 05:54:35 PM
-
TCL16beta1 x86_64 with full Xorg (Xorg-7.7-3d.tcz) powers the laptop that serves as my family media player/entertainment center.
My sons would love to play this game (https://github.com/endless-sky/endless-sky/releases/download/v0.10.12/Endless_Sky-v0.10.12-x86_64.AppImage) on the entertainment center, but no luck:
$ export FUSERMOUNT_PROG=/usr/local/bin/fusermount
$ ./Endless_Sky-v0.10.12-x86_64.AppImage
./Endless_Sky-v0.10.12-x86_64.AppImage: error while loading shared libraries: libOpenGL.so.0: cannot open shared object file: No such file or directory
If I grab the missing library from Debian, the game errors out due to missing libGLdispatch.so.0 (provided by libglvnd0.deb). If I also grab that missing library, then the game does not complain about any missing libraries but fails silently.
I hope it's not naive to think that the game might work if libOpenGL.so.0 and libGLdispatch.so.0 are provided by proper TCL extensions.
-
Hi GNUser
Seems you are not the only person to run into this:
https://github.com/endless-sky/endless-sky/issues/8137
-
Hi Rich. I discovered that both libraries are compiled from the same source tarball--this one: https://gitlab.freedesktop.org/glvnd/libglvnd/-/archive/v1.7.0/libglvnd-v1.7.0.tar.gz
I will submit libglvnd.tcz and libglvnd-dev.tcz for the TCL16 x86_64 repo.
-
I submitted those extensions. With libglvnd.tcz loaded I'm getting warmer but still not joy:
$ export FUSERMOUNT_PROG=/usr/local/bin/fusermount
$ ./Endless_Sky-v0.10.12-x86_64.AppImage
Unable to query the OpenGL version!
I can't figure this out. Xorg-7.7-3d is loaded so I should have 3d/OpenGL support, right? Any ideas where to go from here?
P.S. It's not a hardware issue because this same game runs on this same laptop with Devuan Daedalus. In Devuan there is no "Unable to query the OpenGL version" error. Running Devuan on this machine is only feasible for testing purposes.
-
Here's the end of an strace in case it helps:
$ strace -e trace=file ./Endless_Sky-v0.10.12-x86_64.AppImage
...
openat(AT_FDCWD, "/proc/meminfo", O_RDONLY) = 11
openat(AT_FDCWD, "/usr/local/share/drirc.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 11
openat(AT_FDCWD, "/usr/local/share/drirc.d/00-mesa-defaults.conf", O_RDONLY) = 11
openat(AT_FDCWD, "/usr/local/share/drirc.d/00-radv-defaults.conf", O_RDONLY) = 11
openat(AT_FDCWD, "/usr/local/etc/drirc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/bruno/.drirc", O_RDONLY) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/home/bruno", {st_mode=S_IFDIR|S_ISGID|0755, st_size=660, ...}, 0) = 0
newfstatat(AT_FDCWD, "/home/bruno/.cache", {st_mode=S_IFDIR|S_ISGID|0700, st_size=100, ...}, 0) = 0
newfstatat(AT_FDCWD, "/home/bruno/.cache", {st_mode=S_IFDIR|S_ISGID|0700, st_size=100, ...}, 0) = 0
newfstatat(AT_FDCWD, "/home/bruno/.cache/mesa_shader_cache", {st_mode=S_IFDIR|S_ISGID|0700, st_size=3100, ...}, 0) = 0
newfstatat(AT_FDCWD, "/home/bruno/.cache/mesa_shader_cache/marker", {st_mode=S_IFREG|0644, st_size=0, ...}, 0) = 0
openat(AT_FDCWD, "/home/bruno/.cache/mesa_shader_cache/index", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 12
syscall_435(0x7fffd6c69ad0, 0x58, 0x7f45075ee106, 0x8, 0x7f44fe5716c0, 0x7fffd6c69bc7) = 0x3d81
newfstatat(AT_FDCWD, "/proc/sys/dev/i915/perf_stream_paranoid", {st_mode=S_IFREG|0644, st_size=0, ...}, 0) = 0
openat(AT_FDCWD, "/proc/sys/dev/i915/perf_stream_paranoid", O_RDONLY) = 12
syscall_435(0x7fffd6c6a600, 0x58, 0x7f45075ee106, 0x8, 0x7f44fdd706c0, 0x7fffd6c6a6f7) = 0x3d82
syscall_435(0x7fffd6c6a5a0, 0x58, 0x7f45075ee106, 0x8, 0x7f44fdd706c0, 0x7fffd6c6a697) = 0x3d83
Unable to query the OpenGL version!
openat(AT_FDCWD, "/home/bruno/.local/share/endless-sky/errors.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
$ cat /home/bruno/.local/share/endless-sky/errors.txt
Unable to query the OpenGL version!
P.S. Rich, this thread has morphed from an extension request (no longer needed because I already created and submitted the extension) to a help request (help fixing game error: "unable to query the OpenGL version"). Kindly change the thread title and move thread to a more appropriate category.
-
Do you get something analogous to this:
glxinfo | grep -i opengl
OpenGL vendor string: Broadcom
OpenGL renderer string: VC4 V3D 2.1
OpenGL version string: 2.1 Mesa 24.2.5
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 24.2.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:
-
Hi Juanito. glxinfo is present neither on my system nor in the repo:
$ glxinfo
sh: glxinfo: not found
$ provides.sh glxinfo
$ Let me do some hacking and try to get this information.
-
$ ./glxinfo | grep -i opengl
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 4000 (IVB GT2)
OpenGL core profile version string: 4.2 (Core Profile) Mesa 24.1.7
OpenGL core profile shading language version string: 4.20
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.2 (Compatibility Profile) Mesa 24.1.7
OpenGL shading language version string: 4.20
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 24.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
I guess this suggests my system is setup correctly? Maybe my system is just missing the utility or text file that the game uses to determine the OpenGL version? The game is free software so I'll take a look at the source code to see if there are any clues there.
-
Hi Juanito. Game's source code has this in GameWindow.cpp:
// Check that the OpenGL version is high enough.
const char *glVersion = reinterpret_cast<const char *>(glGetString(GL_VERSION));
if(!glVersion || !*glVersion)
{
ExitWithError("Unable to query the OpenGL version!");
return false;
}libGL-dev.tcz has /usr/local/include/GL/gl.h with this function prototype:
GLAPI const GLubyte * GLAPIENTRY glGetString( GLenum name );
It seems the game is going through proper channels to get the OpenGL version. I see that libGL.tcz is very new, so that excludes the GL version being too old.
I'm running out of ideas. I'll post the output of glxinfo | grep -i opengl when running Devuan on this same machine (game works fine) to see if there are any clues there.
-
Here's the output from Devuan running on this same laptop, where game has no issue even though the Mesa version is older (22.3.6 vs. TCL16's 24.1.7):
Devuan$ glxinfo | grep -i opengl
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 4000 (IVB GT2)
OpenGL core profile version string: 4.2 (Core Profile) Mesa 22.3.6
OpenGL core profile shading language version string: 4.20
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.2 (Compatibility Profile) Mesa 22.3.6
OpenGL shading language version string: 4.20
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 22.3.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
Any ideas why the game cannot query the OpenGL version when running in TCL16 x86_64?
-
You could try strace again to find where it’s looking for gl.h and what it reports?
-
I think it would only look for gl.h at compile time. The error I'm encountering happens at runtime when I try running the AppImage provided by the developers.
-
Just an aside: My kids also like playing Minecraft (Java version). It works on Devuan but spits out similar errors on TCL. I'm hopeful that if we can fix this issue for Endless Sky, it will address similar problems in other games.
-
You could try strace again to find where it’s looking for gl.h and what it reports?
$ export FUSERMOUNT_PROG=/usr/local/bin/fusermount
$ strace ./Endless_Sky-v0.10.12-x86_64.AppImage >strace.txt 2>&1
Hi Juanito. Here's a full strace in case it helps:
https://gnuser.ddns.net/public/strace.txt
I'm highly motivated to solve this. I'll be happy to provide whatever information you think may be helpful.
-
When using strace it's default behavior is not to follow forks, so if the program forks you have trace for only the main process.
So if you add option -f it will follow the fork.
strace -f ./Endless_Sky-v0.10.12-x86_64.AppImage >strace.txt 2>&1
@GNUser
Have you tried to use another user like root, if the problem is with some rights.
-
Hi patrikg. Thanks for the tip.
https://gnuser.ddns.net/public/strace-forking.txt
-
@GNUser
Have you tried to use another user like root, if the problem is with some rights.
I had not tried as root, that's a good thought. Alas, it makes no difference.
-
Hi Juanito. By hacking on this AppImage pretty hard and comparing how it behaves in TCL vs. Devuan, I was able to make a discovery: The AppImage depends on libGLX_mesa (in one place I think it also looks for libGLX_indirect, which is just a link to libGLX_mesa). This is where the files are located in the Debian/Devuan filesystem:
bruno@Devuan:/usr/lib/x86_64-linux-gnu$ ls -l libGLX_*
lrwxrwxrwx 1 root root 16 Mar 22 2023 libGLX_indirect.so.0 -> libGLX_mesa.so.0
lrwxrwxrwx 1 root root 20 Mar 22 2023 libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rw-r--r-- 1 root root 455416 Mar 22 2023 libGLX_mesa.so.0.0.0
It's not obvious to me how to compile libGLX_mesa. Do you have time/interest in adding this to TCL16 x86_64's repo?
-
If these missing libraries find their way to repo, I'll give it another shot. If not, no biggie.
It seems games on Linux are a can of worms. I'm beginning to wish I hadn't messed with this.
-
If you don't messing(plays) with things you stopping learning.
The best thing, how to learn things is by using "edutainment" as a guide.
-
Despite extensive experimentation I was not able to get precompiled games requiring 3d to work on TCL16 x86_64 with Xorg-7.7-3d.
Most such games I've tried (e.g., Endless Sky, Pioneer, Minecraft Java Edition) do not work at all on TCL16. Others (e.g., 0ad) work on TCL16 but sometimes crash. All of these games work perfectly on Devuan Daedalus.
Most if not all critical packages are at older versions on Devuan Daedalus than they are on TCL16, so extensions' age/version is most likely not the problem.
I solved my problem (well, more like worked around it) by converting the family media player into a dual-boot machine: TCL16 is the default OS, Devuan is there just for 3d games.
It seems precompiled games are making some assumptions about available libraries and/or location of libraries that are true for most distros but not true for TCL. But this is just a guess because I cannot pinpoint the problem--the error messages these games are giving are not specific enough.
IMHO TCL is already a perfect OS for general-purpose computing, routers, and a long list of other applications. It is currently not well suited for gaming but it may be just a matter of adding a small number of libraries and/or moving (or symlinking) some things.
I'm available to help with packaging and/or testing if the developers would like to fine tune TCL so that it also excels at running precompiled games. If gaming is outside TCL's target uses, that's fine too. Maybe it would be merciful to other distros to leave at least one domain where other distros can do a better job. We don't want to embarrass the competition too much :)
-
Are the games multi-lib?
-
Are the games multi-lib?
No. They are pure x86_64. My Devuan partition is not setup for multilib but can handle these games.
I know to stay away from multi-lib because it's unsupported on TCL and, on OSes that support it (e.g., Debian/Devuan), setting up multilib adds a lot of packages/complexity to the system.
-
Hi Juanito. The initial problem with these games is obvious. Endless Sky and Pioneer both need libOpenGL:
$ ./Pioneer-x86_64.AppImage
usr/bin/pioneer: error while loading shared libraries: libOpenGL.so.0: cannot open shared object file: No such file or directory
$ export FUSERMOUNT_PROG=/usr/local/bin/fusermount
$ ./Endless_Sky-v0.10.12-x86_64.AppImage
./Endless_Sky-v0.10.12-x86_64.AppImage: error while loading shared libraries: libOpenGL.so.0: cannot open shared object file: No such file or directory
This can be solved by loading libglvnd.tcz (which I recently submitted for TCL16 x86_64).
Once libglvnd is loaded, a new problem presents itself (one without an obvious solution):
$ tce-load -wi libglvnd
libglvnd is already downloaded.
libglvnd.tcz: OK
$ ./Pioneer-x86_64.AppImage
Info: ver 20250203 (586b518) on: Linux
Info: System Name: Linux
Host Name: x230
Release(Kernel) Version: 6.12.11-tinycore64
Kernel Build Timestamp: #1 SMP Sun Jan 26 16:50:13 UTC 2025
Machine Arch: x86_64
Domain Name: (none)
Info: Loaded mods:
Info: --------------------
Info: SDL Version (build) 2.0.10
Info: SDL Version (dynamic) 2.0.10
Info: SDL Versions match
Info: SDL_image Version (build): 2.0.5
Info: SDL_image Version (dynamic): 2.0.5
Info: SDL_image Versions match
Info: Assimp Version: 5.0.0
Info: FreeType Version: 2.10.1
Info: GLEW dynamic version: 2.0.0
Info: --------------------
Info:
Info: SDL video driver used: x11
Fatal: GLEW initialisation failed: Missing GL versionBoth Endless Sky and Pioneer complain about missing GL version. Either I screwed up when I built libglvnd.tcz or else the libGL.tcz (or one of the other 3d libraries) is not providing the GL version.
-
Does this help:
export LD_PRELOAD=/usr/local/lib/libGLEW.so
Are you using glew or glew2?
Do you have freeglut loaded?
-
In your libglvnd extension you are duplicating files in the Xorg-7.7-3d, libGL, libGLESv2 and libEGL extensions:
/usr/local/lib/libGLX.so
/usr/local/lib/libGLX.so.0
/usr/local/lib/libOpenGL.so.0
/usr/local/lib/libOpenGL.so
/usr/local/lib/libGLESv1_CM.so
/usr/local/lib/libOpenGL.so.0.0.0
/usr/local/lib/libGLESv2.so
/usr/local/lib/libEGL.so.1.1.0
/usr/local/lib/libGLX.so.0.0.0
/usr/local/lib/libGLESv2.so.2.1.0
/usr/local/lib/libGLESv2.so.2
/usr/local/lib/libEGL.so.1
/usr/local/lib/libGLESv1_CM.so.1.2.0
/usr/local/lib/libGLESv1_CM.so.1
/usr/local/lib/libGL.so.1
/usr/local/lib/libGLdispatch.so.0
/usr/local/lib/libGLdispatch.so
/usr/local/lib/libEGL.so
/usr/local/lib/libGL.so
/usr/local/lib/libGLdispatch.so.0.0.0
/usr/local/lib/libGL.so.1.7.0
i.e. libGLESv1_CM.so, libGLESv1_CM.so.1, libGLESv2.so, libGLESv2.so.2, libEGL.so, libEGL.so.1, libGL.so, libGL.so.1
Loading libglvnd after Xorg-7.7-3d will not overwrite these symlinks, which may cause problems as the symlinks will still point to the libs in Xorg-7.7-3d, libGL, libGLESv2 and libEGL.
Conversely, if you load linglvnd before Xorg-7.7-3d, the symlinks will point to the libglvnd libs and not Xorg-7.7-3d, libGL, libGLESv2 and libEGL, which will possibly cause issues with the x11 display.
Note the difference in lib names: /usr/local/lib/libEGL.so.1.1.0
/usr/local/lib/libGLESv2.so.2.1.0
/usr/local/lib/libGLESv1_CM.so.1.2.0
/usr/local/lib/libGL.so.1.7.0
vs /usr/local/lib/libEGL.so.1.0.0
/usr/local/lib/libGLESv2.so.2.0.0
/usr/local/lib/libGLESv1_CM.so.1.1.0
/usr/local/lib/libGL.so.1.2.0
-
Hi Juanito. Your suggestions led me to the solution :)
glew, glew2, and freeglut were not loaded but do not seem to be needed.
$ tce-status -i | grep glew
$ tce-status -i | grep freeglut
$ tce-status -i | grep GL
libEGL
libGL
libGLESv2
The secret for these games to work are these two commands:
$ tce-load -wi libglvnd
$ export LD_PRELOAD=/usr/local/lib/libGL.soNow Endless Sky, Pioneer, and Minecraft Java Edition are all working :) Gosh, I'm so happy I'll be able to ditch the dual-boot situation and do everything in TCL!
Do you think it's a fair assumption that the root cause here is that one or more binaries in these precompiled games is/are looking for libGL.so in the wrong place?
P.S. 0ad continues to crash but seems to be an issue unrelated to what we were trying to solve in this thread. The thread may be marked as Solved.
-
Hi Juanito. Let me do some experiments and see whether a more minimal version of libglvnd is sufficient. I'll report back in a few minutes.
-
Do you think it's a fair assumption that the root cause here is that one or more binaries in these precompiled games is/are looking for libGL.so in the wrong place?
It's possible it was looking in something like /usr/lib/x86_64-linux-gnu/ or similar
-
Do you think it's a fair assumption that the root cause here is that one or more binaries in these precompiled games is/are looking for libGL.so in the wrong place?
It's possible it was looking in something like /usr/lib/x86_64-linux-gnu/ or similar
Gosh, and to think a simple LD_PRELOAD was the answer. I would not have figured this one out without your help. Thanks a lot.
Regarding libglvnd, a trimmed-down extension that provides only the libraries not provided elsewhere (i.e., libGLdispatch, libGLX, libOpenGL) is sufficient. I'll send you a PM with new libglvnd.tcz submission.
Please trim libglvnd-dev.tcz as you think best. I'm not sure I could trim it myself and get it right.
-
Hi GNUser
... The thread may be marked as Solved.
Done. :)