Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: GNUser on December 08, 2020, 03:19:19 PM
-
Since the recent Xorg-7.7-3d.tcz upgrade to version 20.3.0, my portable version of xscreensaver fails with this kind of error:
glmatrix: display ":0.0" does not support the GLX extension.
glknots: display ":0.0" does not support the GLX extension.
glmatrix: display ":0.0" does not support the GLX extension.
lockward: display ":0.0" does not support the GLX extension.
geodesic: display ":0.0" does not support the GLX extension.
glmatrix: display ":0.0" does not support the GLX extension.
Any ideas how to fix, short of reverting to Xorg-7.7-3d.tcz version 19.2.3?
-
Did you update libEGL, libGL and libGLESv2 at the same time?
-
The system is fully updated, so I assume those extensions were updated at the same time.
bruno@x200:~$ cat /opt/tcemirror
http://repo.tinycorelinux.net/
bruno@x200:~$ tce-update
Checking for Easy Mode Operation... OK
Press Enter key to begin batch update of extensions in /sda3/tce
or enter any char to exit now:
Checking Tiny Core Applications in /mnt/sda3/tce/optional
Your system is up-to-date.
Press Enter key.
bruno@x200:~$ tce-status -i | grep 'lib.*GL'
libEGL
libGL
libGLESv2
I can confirm that on this fully-updated TCL11.1 x86_64 machine, the problem goes away if I go into tce/optional/ and replace newest Xorg-7.7-3d.tcz with previous version then reboot.
-
Maybe the portable application has a built-in, older version of one or more of these libraries. I'll check.
-
Hi GNUser
You could try this to see if it reveals anything:
ldd /Path/To/xscreensaver
-
Hi GNUser
If you load mesa-demos.tcz does this run without errors:
glxinfo
-
Hi, Rich. Thanks for the suggestions.
$ ldd /opt/bin/xscreensaver
/opt/bin/xscreensaver: error while loading shared libraries: /opt/bin/xscreensaver: ELF file ABI version invalid
$ tce-load -wi mesa-demos
...
$ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
The ldd error doesn't bother me because I get the same error with all other AppImages, including ones that are working perfectly.
The glxinfo is more concerning. I will see if the error goes away when I load the older version of Xorg-7.7-3d.
-
Everything points to a problem with the new version of Xorg-7.7-3d.tcz.
If I change nothing except replace new version of said extension with old version then reboot, then glxinfo works fine:
$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_no_error,
GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float,
GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample,
...
-
Hi GNUser
Looking at the dates in the .info files:
mesa-demos.tcz 2019/11/11 recompiled against mesa-19.2.3
Xorg-7.7-3d.tcz 2020/12/06 updated 19.2.3 -> 20.3.0I'm guessing glxinfo may have failed because mesa-demos depends on Xorg-7.7-3d which was compiled after mesa-demos.
-
Check your Xorg.0.log for any 3d/drm errors.
-
I tested the update for several days before posting - I just checked again and glxgears/glxinfo, vkcube/vulkaninfo, xscreensaver and others all work as expected.
$ glxinfo | grep 20.3
Version: 20.3.0
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.3.0
OpenGL version string: 3.0 Mesa 20.3.0
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.3.0
-
curaga, Xorg.0.log does not seem to contain any related errors: https://pastebin.com/mmFyP7te
I'm stuck because system is supposedly fully updated using official repo, but I can't get past this:
bruno@x200:~$ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
Maybe it has something to do with my graphics hardware? Graphics is really not my forte. My machine is an X200 ThinkPad with integrated Intel graphics and Libreboot.
I'll revert to older Xorg-7.7-3d.tcz for now.
-
Hi GNUser
curaga, Xorg.0.log does not seem to contain any related errors: https://pastebin.com/mmFyP7te ...
Wouldn't this be suspect:
[ 25.306] (II) Initializing extension GLX
[ 25.314] (EE) AIGLX error: dlopen of /usr/local/lib/dri/i965_dri.so failed (libzstd.so.1: cannot open shared object file: No such file or directory)
[ 25.314] (EE) AIGLX error: unable to load driver i965
[ 25.334] (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (libzstd.so.1: cannot open shared object file: No such file or directory)
[ 25.334] (EE) AIGLX error: unable to load driver swrast
[ 25.334] (EE) GLX: could not load software renderer
[ 25.334] (II) GLX: no usable GL providers found for screen 0
----- Snip -----
[ 25.935] (II) Initializing extension GLX
[ 25.936] (EE) AIGLX error: dlopen of /usr/local/lib/dri/i965_dri.so failed (libzstd.so.1: cannot open shared object file: No such file or directory)
[ 25.936] (EE) AIGLX error: unable to load driver i965
[ 25.936] (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (libzstd.so.1: cannot open shared object file: No such file or directory)
[ 25.936] (EE) AIGLX error: unable to load driver swrast
[ 25.936] (EE) GLX: could not load software renderer
[ 25.936] (II) GLX: no usable GL providers found for screen 0
-
Yes, that sure does seem suspect. Strangely, zstd.tcz is loaded, /usr/local/lib/dri/i965_dri.so exists, and /usr/local/lib/dri/swrast_dri.so also exists.
I'm going to fudge the .md5.txt files of all related extensions, to force them to be re-downloaded from official repo during "tce-update". Let's see if that fixes it.
-
Hi GNUser
... I'm going to fudge the .md5.txt files of all related extensions, to force them to be re-downloaded from official repo during "tce-update". Let's see if that fixes it.
This has always worked to update everything:
tce-audit builddb
tce-audit updatedeps
tce-audit fetchmissing
tce-updateThen click the Exit icon and select reboot.
By the way, if any of your extensions is missing its .md5.txt file, it won't get updated.
-
Strangely, zstd.tcz is loaded, /usr/local/lib/dri/i965_dri.so exists, and /usr/local/lib/dri/swrast_dri.so also exists.
If zstd is loaded, then libzstd should be loaded and you wouldn't get the error - 3d acceleration will not work without it. I'd guess that you have an error in a dep file or a missing dep file somewhere.
-
Rich: All extensions in my tce/optional/ directory have an associated .md5.txt file except mylocale.tcz.
juanito: Yes, that was the problem. The zstd.tcz is up-to-date but zstd.tcz.dep does not exist for some reason, so libzstd.tcz and liblz4.tcz were not loaded. I'm not sure why the .dep file is missing from my system. I certainly did not delete it.
I grabbed zstd.tcz.dep from the repository, then fetched missing dependencies. Both libzstd.tcz and liblz4.tcz trickled in. After a reboot, all problems resolved.
Thread may be marked as Solved.
P.S. What's the most plausible explanation for the missing .dep file? I'm quite surprised by this.
-
btw - after the initial upload, I corrected the Xorg-7.7-3d dep file to contain libzstd instead of zstd.
-
Thanks, juanito! :)
It seems the package management system has a tiny flaw: It has no way to fetch corrected/changed .dep files unless the extension itself (and it's md5 sum) also changes.
The solution would be for the md5 sum to somehow be calculated based on the contents of both the .tcz and .tcz.dep files, but I can imagine this would not be easy to implement.
P.S. After forcing a re-download of all affected extensions (including their .dep files), I see that zstd.tcz is now an orphan (i.e., no extensions depend on it). Indeed, Xorg-7.7-3d does not need it--it only needs libzstd.tcz. I have removed all orphaned extensions from my system and things are still working perfectly.
-
Hi, GNUser!
Sorry, I didn't understood from the thread, why the old version was working properly? Doesn't it uses zstd? This is just a curiosity.
One more question: if extension .dep file is updated with some changes, it will not be noticed by the local system? Of course this is low probability event but seems to be possible. Maybe during tce-update not only md5 but dep too needs to be compared?
-
The old version didn’t use libzstd.
-
Hi, jazzbiker.
Yes, tce-update compares md5 of the extension but does not compare the .dep files.
Either of these would have fixed my issue of missing libzstd:
1) Keep the Xorg-7.7-3d.tcz.dep file that my system downloaded when it upgraded that extension (which listed zstd.tcz as a dependency), fix the issue that zstd.tcz.dep was missing
-or-
2) Download juanito's corrected Xorg-7.7-3d.tcz.dep file (which lists libzstd.tcz as a dependency)
After either of the above, "tce-update" (or "tce-audit fetchmissing") would have discovered that libzstd.tcz was missing from my system and would have fixed my problem.
Since "tce-update" cannot detect missing or changed .dep files, I was out of luck. It's a bug with low probability of affecting a user, but I was affected by it twice in this scenario. Lucky me!
-
Lucky You!
Not so long ago I've caight even trickier event while using tce-update, not a bug, it can be better named bingo! I even didn't reported about it on the forum, due to its impossibility to meet with. For some reasons I expect myself to be the only one to get acquainted with it. But exploring this bingo-bug I've noticed, that opposite to tce-update, Apps didn't check dependencies during update.
So what am I to do in case if I have an extension submitted (let's imagine) and I want to update its dep file? Should I apply the meaningless changes into tcz file in order to get all the trio to be updated?
-
So what am I to do in case if I have an extension submitted (let's imagine) and I want to update its dep file? Should I apply the meaningless changes into tcz file in order to get all the trio to be updated?
Yes, under the current system the only way for extension maintainer to make sure users get the updated .dep file during "tce-update" is for maintainer to make meaningless changes to the tcz file so that its md5sum changes.
If user wants to manually ensure that the whole trio is updated, it's enough to go into tce/optional/foo.tcz.md5.txt and change some random characters of the md5sum prior to running "tce-update".
-
Probably for the second case user will be happy to have some option for tce-load to force refreshing. We suppose that he faced some problems with selected extension and is haunting the way to eliminate them.
But extension, that cause the trouble today could be updated a month ago... Distorting all the existing md5 files don't looks an elegant solution, its like a hammer strike.
-
IIRC there is an "update .dep files" option in Apps, not sure what it's called in the cli scripts.
-
Hi curaga
IIRC there is an "update .dep files" option in Apps, ...
So there is:
Click Apps->Maintenance->Dependencies And Deletions
Click Apps->Update .dep files.
-
I just found this (thanks for the tip, curaga!):
tce-audit updatedepsIt doesn't tell you what it's doing while it runs, but I tested it (randomly deleted some .dep files and changed others) and the command fixed everything.
I will make it a habit of running this command in combination with "tce-update".
EDIT: I looked at the tce-audit script and the reason the reason "tce-audit updatedeps" doesn't say much is because it's not making any fancy decisions--it simply downloads a fresh copy of each extension's .dep file (if one exists in the repo). Simple and effective, like all things TCL :)
-
Oh, that's nice! Thanks, Curaga and Rich!
-
Hi GNUser
I believe I included that command in my earlier post ::):
... This has always worked to update everything:
tce-audit builddb
tce-audit updatedeps
tce-audit fetchmissing
tce-updateThen click the Exit icon and select reboot. ...
-
Eek! :-[
Well, that's embarrassing! I need to pay more attention.
I will create a script with these commands so that I never miss it again.
Well, at least now I know exactly what "tce-audit updatedeps" does and what can potentially go wrong without it.