bug#64981: GTK4 applications broken (missing libGLESv2)

bug#64981: GTK4 applications broken (missing libGLESv2)

[Csepp]

for example:
$ transmission-gtk
Couldn't open libGLESv2.so.2: libGLESv2.so.2

I get the same error with Tuba.  It likely affects other applications.

Guix commit: 182be30
System: x86_64

bug#64981: GTK4 applications broken (missing libGLESv2)

[Liliana Marie Prikler]

tags 64981 moreinfo
thanks

Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp:
> for example:
> $ transmission-gtk
> Couldn't open libGLESv2.so.2: libGLESv2.so.2
> 
> I get the same error with Tuba.  It likely affects other
> applications.
I assume you are not using the gnome-desktop-service, are you?

Neither transmission-gtk nor GTK4 appears to actually link against
libGLES, so there's probably something arcane going on already.  Have
you tried the usual debugging tools (GDB, strace)?

Cheers 

bug#64981: GTK4 applications broken (missing libGLESv2)

[Csepp]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> tags 64981 moreinfo
> thanks
>
> Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp:
>> for example:
>> $ transmission-gtk
>> Couldn't open libGLESv2.so.2: libGLESv2.so.2
>> 
>> I get the same error with Tuba.  It likely affects other
>> applications.
> I assume you are not using the gnome-desktop-service, are you?

Yup, I'm using Sway without a display manager.  Gnome was a memory hog.

> Neither transmission-gtk nor GTK4 appears to actually link against
> libGLES, so there's probably something arcane going on already.  Have
> you tried the usual debugging tools (GDB, strace)?
>
> Cheers 

Not yet, but I did now:

```
$ strace -e %file transmission-gtk |& grep libGL                                                :(
openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLX.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/libGL.so.1", O_RDONLY|O_CLOEXEC) = 29
openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLESv2.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libGLESv2.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory
```

So it's not looking for it in Mesa, which is odd, isn't that where it's
supposed to be?  According to guix locate libGLESv2.so.2, it should be
in one of the Mesa packages.

Thanks for helping me look into this!  Gonna look a bit more into what's
going on...

bug#64981: GTK4 applications broken (missing libGLESv2)

[paren--- via Bug reports for GNU Guix]

Csepp <raingloom@riseup.net> writes:
>> Am Dienstag, dem 01.08.2023 um 00:06 +0200 schrieb Csepp:
>>> for example:
>>> $ transmission-gtk
>>> Couldn't open libGLESv2.so.2: libGLESv2.so.2
>>> 
>>> I get the same error with Tuba.  It likely affects other
>>> applications.
>> I assume you are not using the gnome-desktop-service, are you?
>
> Yup, I'm using Sway without a display manager.  Gnome was a memory hog.

Oddly, GTK 4 apps work fine for me on Sway.

  -- (

bug#64981: GTK4 applications broken (missing libGLESv2)

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 12890 bytes --]

Hi,

I've the same issue for several programs.

I'm using sway and I tried to use dino.

I've built dino like that:
> guix install dino \
> 	--with-debug-info=gtk \
> 	--with-debug-info=glib \
> 	--with-debug-info=glibc \
> 	--with-debug-info=libepoxy
> 
> cat $(which dino) | sed 's#exec -a "$0" #exec -a "$0" gdb #g' > dino
> chmod +x dino

And here's my gdbinit:
> $ cat ~/.gdbinit 
> guile
> (use-modules (gdb))
> (execute (string-append "set debug-file-directory "
>                         (or (getenv "GDB_DEBUG_FILE_DIRECTORY")
>                             "~/.guix-profile/lib/debug")))
> end

Then I run ./dino and I get that:
> $ ./dino 
> GNU gdb (GDB) 12.1
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /gnu/store/qhc45j9hjspvig6m1wjvx4nxpjwsnq4d-dino-0.4.2/bin/.dino-real...
> (No debugging symbols found in /gnu/store/qhc45j9hjspvig6m1wjvx4nxpjwsnq4d-dino-0.4.2/bin/.dino-real)
> (gdb) run
> Starting program: /gnu/store/qhc45j9hjspvig6m1wjvx4nxpjwsnq4d-dino-0.4.2/bin/.dino-real 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libthread_db.so.1".
> [New Thread 0x7ffff33ff640 (LWP 27192)]
> [Thread 0x7ffff33ff640 (LWP 27192) exited]
> [New Thread 0x7ffff33ff640 (LWP 27193)]
> [New Thread 0x7ffff1bf4640 (LWP 27194)]
> [Detaching after fork from child process 27195]
> [New Thread 0x7ffff13f3640 (LWP 27196)]
> [New Thread 0x7ffff0bea640 (LWP 27197)]
> [New Thread 0x7fffe3611640 (LWP 27198)]
> [New Thread 0x7fffe2e10640 (LWP 27199)]
> [New Thread 0x7fffe260f640 (LWP 27200)]
> [New Thread 0x7fffe1e0e640 (LWP 27201)]
> [Thread 0x7fffe260f640 (LWP 27200) exited]
> [New Thread 0x7fffe260f640 (LWP 27202)]
> [Thread 0x7fffe1e0e640 (LWP 27201) exited]
> [New Thread 0x7fffe1e0e640 (LWP 27203)]
> [Thread 0x7fffe260f640 (LWP 27202) exited]
> [Thread 0x7fffe1e0e640 (LWP 27203) exited]
> [New Thread 0x7fffe1e0e640 (LWP 27204)]
> [New Thread 0x7fffe260f640 (LWP 27205)]
> [Thread 0x7fffe1e0e640 (LWP 27204) exited]
> [Thread 0x7fffe260f640 (LWP 27205) exited]
> [New Thread 0x7fffe260f640 (LWP 27206)]
> [New Thread 0x7fffe1e0e640 (LWP 27207)]
> [Thread 0x7fffe260f640 (LWP 27206) exited]
> [Thread 0x7fffe1e0e640 (LWP 27207) exited]
> [New Thread 0x7fffe1e0e640 (LWP 27208)]
> [New Thread 0x7fffe260f640 (LWP 27209)]
> [New Thread 0x7fffe1318640 (LWP 27210)]
> [New Thread 0x7fffe0b17640 (LWP 27211)]
> [New Thread 0x7fffbf3ff640 (LWP 27212)]
> [New Thread 0x7fffbebfe640 (LWP 27213)]
> [New Thread 0x7fffabfff640 (LWP 27214)]
> [New Thread 0x7fffab7fe640 (LWP 27215)]
> [New Thread 0x7fffaaffd640 (LWP 27216)]
> Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory
> 
> Thread 1 ".dino-real" received signal SIGABRT, Aborted.
> 0x00007ffff48e4fec in __pthread_kill_implementation () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
> (gdb) bt
> #0  0x00007ffff48e4fec in __pthread_kill_implementation ()
>    from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
> #1  0x00007ffff489b202 in raise () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
> #2  0x00007ffff488645b in abort () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6
> #3  0x00007ffff4590eb5 in get_dlopen_handle (load=true, exit_on_fail=true, 
>     lib_name=0x7ffff45b26d3 "libGLESv2.so.2", handle=0x7ffff45ff028 <api+72>)
>     at ../source/src/dispatch_common.c:316
> #4  get_dlopen_handle (handle=0x7ffff45ff028 <api+72>, lib_name=0x7ffff45b26d3 "libGLESv2.so.2", 
>     exit_on_fail=<optimized out>, load=<optimized out>) at ../source/src/dispatch_common.c:293
> #5  0x00007ffff4591842 in epoxy_gles2_dlsym (name=0x7ffff45a536b <entrypoint_strings+25867> "glGetString")
>     at ../source/src/dispatch_common.c:722
> #6  epoxy_gles2_dlsym (name=0x7ffff45a536b <entrypoint_strings+25867> "glGetString")
>     at ../source/src/dispatch_common.c:717
> #7  epoxy_get_bootstrap_proc_address (name=0x7ffff45a536b <entrypoint_strings+25867> "glGetString")
>     at ../source/src/dispatch_common.c:835
> #8  0x00007ffff4534303 in gl_single_resolver (provider=provider@entry=PROVIDER_always_present, 
>     entrypoint_offset=<optimized out>, entrypoint_offset@entry=25867) at src/gl_generated_dispatch.c:75810
> #9  0x00007ffff454485f in epoxy_glGetString_resolver () at src/gl_generated_dispatch.c:89821
> #10 epoxy_glGetString_global_rewrite_ptr (name=7938) at src/gl_generated_dispatch.c:50154
> #11 0x00007ffff4590cd5 in epoxy_internal_gl_version (version_string=version_string@entry=7938, 
>     error_version=error_version@entry=0, factor=factor@entry=10) at ../source/src/dispatch_common.c:397
> #12 0x00007ffff4591091 in epoxy_gl_version () at ../source/src/dispatch_common.c:437
> #13 0x00007ffff5480bb5 in gdk_gl_context_check_extensions (context=0xd065e0)
>     at ../gtk-4.8.1/gdk/gdkglcontext.c:1498
> #14 gdk_gl_context_make_current (context=0xd065e0) at ../gtk-4.8.1/gdk/gdkglcontext.c:1605
> #15 0x00007ffff54afd18 in gsk_gl_renderer_realize (error=0x7fffffffa978, surface=<optimized out>, 
>     renderer=0xc68200) at ../gtk-4.8.1/gsk/gl/gskglrenderer.c:123
> #16 gsk_gl_renderer_realize (renderer=0xc68200, surface=<optimized out>, error=0x7fffffffa978)
>     at ../gtk-4.8.1/gsk/gl/gskglrenderer.c:86
> #17 0x00007ffff5498fa7 in gsk_renderer_realize (renderer=renderer@entry=0xc68200, 
>     surface=surface@entry=0xb8c0b0, error=error@entry=0x7fffffffa978) at ../gtk-4.8.1/gsk/gskrenderer.c:309
> #18 0x00007ffff5499786 in gsk_renderer_new_for_surface (surface=surface@entry=0xb8c0b0)
>     at ../gtk-4.8.1/gsk/gskrenderer.c:649
> #19 0x00007ffff5322ad8 in gtk_window_realize (widget=0x95c2f0) at ../gtk-4.8.1/gtk/gtkwindow.c:4294
> #20 0x00007ffff4ba64ef in g_closure_invoke ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #21 0x00007ffff4bb7f6d in ?? ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #22 0x00007ffff4bbe689 in g_signal_emit_valist ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #23 0x00007ffff4bbebb2 in g_signal_emit ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #24 0x00007ffff5315931 in gtk_widget_realize (widget=0x95c2f0) at ../gtk-4.8.1/gtk/gtkwidget.c:3412
> #25 0x00007ffff5327a72 in gtk_window_show (widget=0x95c2f0) at ../gtk-4.8.1/gtk/gtkwindow.c:3818
> #26 0x00007ffff4ba6719 in ?? ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #27 0x00007ffff4bbea16 in g_signal_emit_valist ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #28 0x00007ffff4bbebb2 in g_signal_emit ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #29 0x00007ffff530acf1 in gtk_widget_show (widget=0x95c2f0) at ../gtk-4.8.1/gtk/gtkwidget.c:2692
> #30 0x00007ffff532559c in gtk_window_present_with_time (window=<optimized out>, timestamp=0)
>     at ../gtk-4.8.1/gtk/gtkwindow.c:5237
> #31 0x00007ffff4ba64ef in g_closure_invoke ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #32 0x00007ffff4bb8306 in ?? ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #33 0x00007ffff4bbe689 in g_signal_emit_valist ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #34 0x00007ffff4bbebb2 in g_signal_emit ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #35 0x00007ffff4cd6328 in ?? ()
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgio-2.0.so.0
> #36 0x00007ffff4cd647e in g_application_run ()
> --Type <RET> for more, q to quit, c to continue without paging--
>    from /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgio-2.0.so.0
> #37 0x000000000042ef77 in main ()

So for some reasons it fails in libepoxy.

So I tried to reproduce the issue:
> $ cat dlopen-test.c
> /*
>  * Copyright © 2023 Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
>  *
>  * This program is free software: you can redistribute it and/or
> modify
>  * it under the terms of the GNU General Public License as published
> by
>  * the Free Software Foundation, either version 3 of the License, or
>  * (at your option) any later version.
>  *
>  * This program is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.
>  *
>  * You should have received a copy of the GNU General Public License
>  * along with this program.  If not, see
> <http://www.gnu.org/licenses/>. */
> 
> #include <assert.h>
> #include <dlfcn.h>
> #include <stdio.h>       
> 
> int main()
> {
> 	void* handle;
> 
> 	assert((RTLD_LAZY|RTLD_LOCAL) == 1);
>        
> 	handle = dlopen("libGLESv2.so.2", RTLD_LAZY|RTLD_LOCAL);
> 
> 	if (handle == NULL) {
> 		fprintf(stderr, "error: %s\n", dlerror());
> 	} else {
> 		printf("handle: %p\n", handle);
> 	}
> 
> 	return 0;
> }

And there it works:
> $ gcc dlopen-test.c
> [gnutoo@primary_laptop dino]$ ./a.out 
> handle: 0x9a52e0

But it somehow fails in my gdb sessions:
> (gdb) set directories ~/debug/rqlhj8xk7x34pnsq8y3gzf7dzwyn9flk-libepoxy-1.5.10-checkout/source/
> (gdb) f 4
> #4  get_dlopen_handle (handle=0x7ffff45ff028 <api+72>, lib_name=0x7ffff45b26d3 "libGLESv2.so.2", 
>     exit_on_fail=<optimized out>, load=<optimized out>) at ../source/src/dispatch_common.c:293
> warning: Source file is more recent than executable.
> 293	get_dlopen_handle(void **handle, const char *lib_name, bool exit_on_fail, bool load)
> (gdb) l
> 288	{
> 289	    library_initialized = true;
> 290	}
> 291	
> 292	static bool
> 293	get_dlopen_handle(void **handle, const char *lib_name, bool exit_on_fail, bool load)
> 294	{
> 295	    if (*handle)
> 296	        return true;
> 297	
> (gdb) 
> 298	    if (!library_initialized) {
> 299	        fputs("Attempting to dlopen() while in the dynamic linker.\n", stderr);
> 300	        abort();
> 301	    }
> 302	
> 303	#ifdef _WIN32
> 304	    *handle = LoadLibraryA(lib_name);
> 305	#else
> 306	    pthread_mutex_lock(&api.mutex);
> 307	    if (!*handle) {
> (gdb) 
> 308	        int flags = RTLD_LAZY | RTLD_LOCAL;
> 309	        if (!load)
> 310	            flags |= RTLD_NOLOAD;
> 311	
> 312	        *handle = dlopen(lib_name, flags);
> 313	        if (!*handle) {
> 314	            if (exit_on_fail) {
> 315	                fprintf(stderr, "Couldn't open %s: %s\n", lib_name, dlerror());
> 316	                abort();
> 317	            } else {
> (gdb) 
> 318	                (void)dlerror();
> 319	            }
> 320	        }
> 321	    }
> 322	    pthread_mutex_unlock(&api.mutex);
> 323	#endif
> 324	
> 325	    return *handle != NULL;
> 326	}
> 327	
> (gdb) p *handle
> $1 = (void *) 0x0

All the above is in Guix system.

The libGLESv2.so.2 comes from libglvnd, but libglvnd is not a
dependency of dino, and I only installed libglvnd with 'guix
package -i libglvnd' and dino is wrapped, so maybe for some reason
it doesn't find libglvnd.

I've tried to add libglvnd in dino inputs, but I got the same error
message (I didn't look at it with gdb though).

But if I install dino with Guix on top of parabola (a host
distribution) then it works fine.

I've also found out that gnome-weather was also complaining about a
missing libGLESv2:
> $ gnome-weather 
> Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory
> Aborted
but I didn't try to debug that.

Probably many more applications (than dino and gnome-weather) are
broken on Guix system.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#64981: GTK4 applications broken (missing libGLESv2)

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

On Tue, Aug 01, 2023 at 12:06:31AM +0200, Csepp wrote:
> for example:
> $ transmission-gtk
> Couldn't open libGLESv2.so.2: libGLESv2.so.2
> 
> I get the same error with Tuba.  It likely affects other applications.
> 
> Guix commit: 182be30
> System: x86_64

I've been getting this too, I'm "glad" to see I'm not the only one.  If
I set GSK_RENDERER=cairo (the fallback renderer) then I can launch gtk4
applications.

(ins)efraim@pbp ~$ guix shell mesa-utils -- glxinfo | grep 'profile version string'
OpenGL core profile version string: 3.1 Mesa 23.1.4
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 23.1.4
(ins)efraim@pbp ~$ guix shell mesa-utils -- eglinfo | grep -B2 -A1 'version string'
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
--
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
--
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#64981: GTK4 applications broken (missing libGLESv2)

[jbranso--- via Bug reports for GNU Guix]

August 15, 2023 4:48 PM, "Efraim Flashner" <efraim@flashner.co.il> wrote:

> I've been getting this too, I'm "glad" to see I'm not the only one. If
> I set GSK_RENDERER=cairo (the fallback renderer) then I can launch gtk4
> applications.
> 
> (ins)efraim@pbp ~$ guix shell mesa-utils -- glxinfo | grep 'profile version string'
> OpenGL core profile version string: 3.1 Mesa 23.1.4
> OpenGL ES profile version string: OpenGL ES 3.1 Mesa 23.1.4
> (ins)efraim@pbp ~$ guix shell mesa-utils -- eglinfo | grep -B2 -A1 'version string'

I am also running into this issue. Efraim's suggestion with changing the GSK_RENDERER
to cairo seems to work for me.  I'm on a Thinkpad T400.

joshua@dobby ~ (master)> guix shell mesa-utils -- glxinfo | grep 'profile version string'
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 23.1.4
joshua@dobby ~ (master)> guix shell mesa-utils -- eglinfo | grep -B2 -A1 'version string' 
libEGL warning: failed to open /dev/dri/card0: Permission denied

libEGL warning: failed to open /dev/dri/card0: Permission denied

EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES 
--
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES 
joshua@dobby ~ (master)> 
joshua@dobby ~ (master)> guix describe
Generation 78	Aug 09 2023 10:13:29	(current)
  guix 210bbf9
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 210bbf9c59355218fec1484a686cc2ecdc218506
  guixrus d70a9ea
    repository URL: https://git.sr.ht/~whereiseveryone/guixrus
    branch: master
    commit: d70a9ea65eba43aba3ec7560d797452c01171b85
  nonguix 1a3082c
    repository URL: https://gitlab.com/nonguix/nonguix
    branch: master
    commit: 1a3082c574077aaf6771ff927e725fc390a2d531
joshua@dobby ~ (master)>

[bug#65375] [PATCH] gnu: libepoxy: Hardcode paths to GLES libraries.

[iyzsong--- via Guix-patches via]

From: 宋文武 <iyzsong@member.fsf.org>

Fixes <https://issues.guix.gnu.org/64981>.

* gnu/packages/gl.scm (libepoxy)[arguments]<#:phases>:
Hardcode paths to libGLESv1_CM.so.1 and libGLESv2.so.2.
---
 gnu/packages/gl.scm | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index b53b42a9ba..f662f0f7da 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -742,10 +742,14 @@ (define-public libepoxy
       #~(modify-phases %standard-phases
           (add-before 'configure 'patch-paths
             (lambda* (#:key inputs #:allow-other-keys)
-              (let ((mesa (dirname (search-input-file inputs "lib/libGL.so"))))
+              (let ((mesa-lib
+                     (lambda (file)
+                       (search-input-file inputs (string-append "lib/" file)))))
                 (substitute* (find-files "." "\\.[ch]$")
-                  (("libGL.so.1") (string-append mesa "/libGL.so.1"))
-                  (("libEGL.so.1") (string-append mesa "/libEGL.so.1")))))))))
+                  (("libGL.so.1") (mesa-lib "libGL.so.1"))
+                  (("libEGL.so.1") (mesa-lib "libEGL.so.1"))
+                  (("libGLESv1_CM.so.1") (mesa-lib "libGLESv1_CM.so.1"))
+                  (("libGLESv2.so.2") (mesa-lib "libGLESv2.so.2")))))))))
     (build-system meson-build-system)
     (native-inputs
      (list pkg-config python))

base-commit: 597af70fd24eb85a85fa8c45008c9cfa241f4d0b
-- 
2.41.0

bug#64981: GTK4 applications broken (missing libGLESv2)

[宋文武 via Bug reports for GNU Guix]

iyzsong@envs.net writes:

> * gnu/packages/gl.scm (libepoxy)[arguments]<#:phases>:
> Hardcode paths to libGLESv1_CM.so.1 and libGLESv2.so.2.

Hello, since we already hardcode paths for libGL, adding libGLES seems
reasonable.

Have test it though, because on my machine (kwin in wayland) it seems
GTK4 applications will use GL renderer instead of GLES.

bug#64981: GTK4 applications broken (missing libGLESv2)

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

Not sure if people saw this patch, has anyone tested if it fixes the
problem for them? I can include it in an upcoming mesa-updates branch
with other related updates/rebuilds.

<https://issues.guix.gnu.org/65375>

Hope I got everyone from the original bug thread (seems many replies
didn't go directly to everyone) and cc'ed the patch number as well.

Thanks!
John

On Sat, Aug 19, 2023 at 10:59 AM, iyzsong@envs.net wrote:

> From: 宋文武 <iyzsong@member.fsf.org>
>
> Fixes <https://issues.guix.gnu.org/64981>.
>
> * gnu/packages/gl.scm (libepoxy)[arguments]<#:phases>:
> Hardcode paths to libGLESv1_CM.so.1 and libGLESv2.so.2.
> ---
>  gnu/packages/gl.scm | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
> index b53b42a9ba..f662f0f7da 100644
> --- a/gnu/packages/gl.scm
> +++ b/gnu/packages/gl.scm
> @@ -742,10 +742,14 @@ (define-public libepoxy
>        #~(modify-phases %standard-phases
>            (add-before 'configure 'patch-paths
>              (lambda* (#:key inputs #:allow-other-keys)
> -              (let ((mesa (dirname (search-input-file inputs "lib/libGL.so"))))
> +              (let ((mesa-lib
> +                     (lambda (file)
> +                       (search-input-file inputs (string-append "lib/" file)))))
>                  (substitute* (find-files "." "\\.[ch]$")
> -                  (("libGL.so.1") (string-append mesa "/libGL.so.1"))
> -                  (("libEGL.so.1") (string-append mesa "/libEGL.so.1")))))))))
> +                  (("libGL.so.1") (mesa-lib "libGL.so.1"))
> +                  (("libEGL.so.1") (mesa-lib "libEGL.so.1"))
> +                  (("libGLESv1_CM.so.1") (mesa-lib "libGLESv1_CM.so.1"))
> +                  (("libGLESv2.so.2") (mesa-lib "libGLESv2.so.2")))))))))
>      (build-system meson-build-system)
>      (native-inputs
>       (list pkg-config python))
>
> base-commit: 597af70fd24eb85a85fa8c45008c9cfa241f4d0b

bug#64981: GTK4 applications broken (missing libGLESv2)

[John Kehayias via Bug reports for GNU Guix]

On Fri, Oct 06, 2023 at 03:47 PM, John Kehayias wrote:

> Hi everyone,
>
> Not sure if people saw this patch, has anyone tested if it fixes the
> problem for them? I can include it in an upcoming mesa-updates branch
> with other related updates/rebuilds.
>
> <https://issues.guix.gnu.org/65375>
>
> Hope I got everyone from the original bug thread (seems many replies
> didn't go directly to everyone) and cc'ed the patch number as well.
>

Pushed as 37fc2c99e0067dfd669526c61dc10d014b89c08b (on mesa-updates
first and then merged to master).

Thanks!