Update to mesa in tc-16.x x86_64 repo

[Juanito]

Due to changes in the structure of the mesa graphics libraries several graphics extensions have been updated in the tc-16.x x86_64 repo.

It is almost certain that some gui extensions will now be missing dependencies, please report these here so it can be fixed.

It is also possible that one or more circular depencies have been created.

Xorg-7.7, Xorg-7.7-3d, Xorg-7.7-3d-vulkan, weston and labwc have all been tested on intel hd4400 haswell graphics hardware

The following have been added/changed/updated:
Xorg-7.7-3d-dev.tcz
Xorg-7.7-3d-vulkan.tcz
Xorg-7.7-3d.tcz
Xorg-7.7-bin.tcz
libEGL-dev.tcz
libEGL.tcz
libGL-dev.tcz
libGL.tcz
libGLESv2-dev.tcz
libGLESv2.tcz
mesa-dev.tcz
mesa-vulkan.tcz
mesa.tcz
weston.tcz
xkbcomp.tcz

The following dep files have changed:
firefox-ESR.tcz.dep
labwc.tcz.dep (missing a dep on xwayland?)
libva22-dev.tcz.dep
libva22.tcz.dep
xorg-server-dev.tcz.dep
xorg-server.tcz.dep

[GNUser]

Hi Juanito. Thank you for these updates, which make it possible to use mesa + wayland compositors without dragging in all of Xorg. This is a really nice upgrade to the TCL repository.

labwc.tcz.dep (missing a dep on xwayland?)

labwc.tcz.dep should not contain xwayland, to accommodate users who want a pure wayland environment. labwc.tcz.info explains how to run labwc with and without xwayland.

[Juanito]

labwc.tcz.dep should not contain xwayland, to accommodate users who want a pure wayland environment. labwc.tcz.info explains how to run labwc with and without xwayland.

Now that you mention it, I do remember you telling me that

[GNUser]

Hi Juanito. meld.tcz was working before these changes but seems to be broken now on TCL16.2 x86_64:

Code: [Select]

$ version
16.2
$ tce-load -wi meld
$ /usr/local/bin/meld

** (meld:14215): WARNING **: 23:38:33.425: Failed to load shared library 'libgtksourceview-3.0.so.1' referenced by the typelib: libglapi.so.0: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "/usr/local/bin/meld", line 384, in <module>
    setup_resources()
  File "/usr/local/bin/meld", line 249, in setup_resources
    GtkSource.StyleSchemeManager.get_default().append_search_path(style_path)
gi.repository.GLib.Error: g-invoke-error-quark: Could not locate gtk_source_style_scheme_manager_get_default: (null) (1)
It seems the problem is that libGL.tcz no longer provides libglapi.so.0

Here are the files that used to be provided by libGL.tcz:

Code: [Select]

/usr/local/lib/libGL.so
/usr/local/lib/libGL.so.1
/usr/local/lib/libGL.so.1.2.0
/usr/local/lib/libglapi.so
/usr/local/lib/libglapi.so.0
/usr/local/lib/libglapi.so.0.0.0
But now only these files are provided:

Code: [Select]

/usr/local/lib/libGL.so
/usr/local/lib/libGL.so.1
/usr/local/lib/libGL.so.1.2.0

[GNUser]

I noticed another small change: xfe file manager used to start practically instantly. After this refactoring of graphics-related packages, xfe now takes about 2 seconds to start. There are no errors or warnings in the terminal.

This change would not be a big deal if xfe were a program that I only ran once in a GUI session. But it's probably the program that gets run and rerun the most times when I'm in a GUI (dozens, or even 100 or more times depending on what I'm doing), so I feel like I'm trekking through molasses.

I'll investigate further and will also try recompiling.

Hi Rich. IIRC you also use xfe. Are you still using it, on TCL16 x86_64? If so, have you also noticed the slowdown?

[Juanito]

It seems the problem is that libGL.tcz no longer provides libglapi.so.0

I checked mesa in piCore64 and that doesn't provide libglapi either.

I'd guess that the functionality provided by libglapi has been moved elsewhere - a quick way to check would be to re-create libglapi with symlinks to libGL, run ldconfig and try again.

Otherwise, when I get a moment, I'll recompile meld against the new mesa and see what happens.

[Juanito]

I noticed another small change: xfe file manager used to start practically instantly.

It's a long shot, but maybe xfe uses a libX* that is no longer loaded to speed things up - I took out Xorg-7.7-lib from the dep chain, maybe you could load it and try again?

It might also be good to check that 3d hardware acceleration is working (if that's what you're using)?

[GNUser]

a quick way to check would be to re-create libglapi with symlinks to libGL, run ldconfig and try again.

Hi Juanito. I'll give that a try and will report back.

I just recompiled xfe and there was no change in speed.

When xfe is starting, since the refactoring of the graphics packages strace shows me nearly 58,000 lines that start with "wait4". These lines look like this:

Code: [Select]

wait4(8193, [{WIFEXITED(s) && WEXITSTATUS(s) == 127}], 0, NULL) = 8193
wait4(8194, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 8194
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, 0x7ffd1e75c7d4, WNOHANG, NULL) = 0
wait4(8195, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 8195
...Does this suggest anything to you?

I have an AppImage that I created from xfe years ago. It still works and is lightning fast. I'll be using it for the time being, but am interested in debugging this and eventually getting back on the repo version of xfe.

[GNUser]

It's a long shot, but maybe xfe uses a libX* that is no longer loaded to speed things up - I took out Xorg-7.7-lib from the dep chain, maybe you could load it and try again?

It might also be good to check that 3d hardware acceleration is working (if that's what you're using)?

I'll check those. Thanks for your input.

[GNUser]

It's a long shot, but maybe xfe uses a libX* that is no longer loaded to speed things up - I took out Xorg-7.7-lib from the dep chain, maybe you could load it and try again?

It might also be good to check that 3d hardware acceleration is working (if that's what you're using)?

I'll check those. Thanks for your input.

Loading Xorg-7.7-lib did not help xfe open any faster.

I do use hardware acceleration for some things (e.g., 3d screensavers, x264 decoding in mpv) but I don't think xfe uses any acceleration.

[GNUser]

a quick way to check would be to re-create libglapi with symlinks to libGL, run ldconfig and try again.

Hi Juanito. Yes, that fixes meld. Thanks.

Code: [Select]

$ cd /usr/local/lib
$ sudo ln -s libGL.so.1.2.0 libglapi.so.0
$ sudo ldconfig
$ meld # now it works :)
As for the other problem (xfe's slowness), I'm not optimistic that I'll find a solution. If I figure it out I'll post the solution here.

[GNUser]

It might also be good to check that 3d hardware acceleration is working

Yes, it's working:

Code: [Select]

$ glxinfo | grep renderer
    GLX_MESA_copy_sub_buffer, GLX_MESA_gl_interop, GLX_MESA_query_renderer,
    GLX_MESA_gl_interop, GLX_MESA_query_renderer, GLX_MESA_swap_control,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa Intel(R) HD Graphics 4000 (IVB GT2)

$ glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 4.2
    Max compat profile version: 4.2
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL core profile version string: 4.2 (Core Profile) Mesa 25.2.5
OpenGL core profile shading language version string: 4.20
OpenGL version string: 4.2 (Compatibility Profile) Mesa 25.2.5
OpenGL shading language version string: 4.20
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 25.2.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00