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.)