Bug#1033230: webkit2gtk: version 2.39.90-1 lost its libgles2 runtime dependency

[Gianfranco Costamagna]

Source: webkit2gtk
Version: 2.40.0-2
Severity: serious

Hello, for some reasons, now webkit2gtk is not linking anymore libGLESv2.so.2 causing surf to fail autopkgtests on arm64 and armhf

autopkgtest [05:16:23]: test command3: timeout -v 5m xvfb-run debian/tests/test_text.sh
autopkgtest [05:16:23]: test command3: [-----------------------

(surf:7196): dbind-WARNING **: 05:16:24.536: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
Could not determine the accessibility bus address
Could not read style file: /home/debci/.surf/styles/default.css
Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory
web process terminated: crashed


Something is trying to load libGLESv2.so.2, but according to webkitgtk build log, that library is now statically built inside webkitgtk?

What is really strange, the detection works, and then its statically built the embedded one?
-- Found OpenGLES2: /usr/lib/aarch64-linux-gnu/libGLESv2.so (found version "3.2")


[2681/6827] : && /usr/bin/cmake -E rm -f lib/libGLESv2.a && /usr/bin/ar crT lib/libGLESv2.a  Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/egl_ext_stubs.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/egl_stubs.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_egl_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_egl_ext_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_1_0_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_2_0_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_3_0_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_3_1_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_3_2_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_ext_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/global_state.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/libGLESv2_autogen.cpp.o Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/proc_table_egl_autogen.cpp.o && /usr/bin/ranlib lib/libGLESv2.a && :

Why ANGLE did change its behaviour is unknown to me, and I find difficult to understand if this is an upstream bug or a Debian specific one.

Gianfranco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-webkit-maintainers/attachments/20230320/42186d2d/attachment.sig>