assumes all GL implementations have glFramebufferTexture2D(), but VirtualBox guest driver doesn't
This is Debian bug 894144.
Since commit c9259c2b "renderer-native: Add hybrid GPU system support", libmutter appears to assume that any implementation of
libGL.so.1 will have
glFramebufferTexture2D and some related symbols. The relevant source code is only conditionally used, but is compiled with ordinary link-time references, not
dlopen() or equivalent. This means that on distributions that link with
-Wl,-z,now ("bind now") as part of a set of security hardening compiler flags, such as Debian, it is a fatal error during gnome-shell startup if the
libGL.so.1 that is first in the search path doesn't have that symbol.
/var/lib/VBoxGuestAdditions/lib/libGL.so.1 from the VirtualBox guest drivers package is an example of a
libGL.so.1 that inserts itself into the library search path and does not export the
glFramebufferTexture2D symbol, breaking mutter-based environments that were linked with
-Wl,-z,now on VirtualBox. The bug reporter tells me this is reproducible with VirtualBox 5.27, but I think that should probably say 5.2.7. The symptom is an error message from the linker:
/usr/bin/gnome-shell: symbol lookup error: /usr/lib/x86_64-linux-gnu/libmutter-2.so.0: undefined symbol: glFramebufferTexture2D
Presumably the solution is to look up these symbols dynamically, with glXGetProcAddress or equivalent; my understanding is that this is what developers are meant to do for the vast majority of GL symbols anyway? I can't help wondering whether mutter should use libepoxy, a GLEW-like convenience wrapper for GL-related symbols, since it already depends on GTK which depends on libepoxy.
(Distributions like to use
-Wl,-z,now globally because it means all relocations can be done during startup and made read-only, which prevents some attacks that involve subverting control flow by overwriting relocations.)