After the GStreamer update in Servo, the nightly binaries have been failingto launch on linux distros unless libegl1-mesa-dev or equivalent package is installed in the runtime environment.
Based on my investigation here, it seems the root cause of the failure is that surfman is trying to dynamically open and load functions from libEGL.so, but on many systems the symlink from libEGL.so to the versioned shared object i.e libEGL.so.1 doesn't exist unless the libegl1-mesa-dev or equivalent package is installed.
Also, the reason the binaries were loading before the GStreamer update was because the binary had a compile-time link to libEGL.so.1 (due to gstreamer-sys crate, which on nightly is not present after the GStreamer upgrade since we have also disabled the media stack). Because of this compile time link, the dlsym calls are able to succesfully load the functions even though the dlopen('libEGL.so') call returns a null handle, indicating failure.
Additionally, @mrobinson found this issue which indicates other bindings like khronos-eglloadlibEGL.so.1 instead of libEGL.so.
This issue is to decide if it is a good idea to do the same in surfman. I don't have expertise in EGL, so I am not sure if we still need a fallback to loading libEGL.so if libEGL.so.1 fails to load, like khronos-egl does. I have tested with a patched surfman that loading libEGL.so.1 does indeed fix the egl function was not loaded issues and Servo continues to work.
After the GStreamer update in Servo, the nightly binaries have been failing to launch on linux distros unless
libegl1-mesa-devor equivalent package is installed in the runtime environment.Based on my investigation here, it seems the root cause of the failure is that surfman is trying to dynamically open and load functions from
libEGL.so, but on many systems the symlink fromlibEGL.soto the versioned shared object i.elibEGL.so.1doesn't exist unless thelibegl1-mesa-devor equivalent package is installed.Also, the reason the binaries were loading before the GStreamer update was because the binary had a compile-time link to
libEGL.so.1(due to gstreamer-sys crate, which on nightly is not present after the GStreamer upgrade since we have also disabled the media stack). Because of this compile time link, thedlsymcalls are able to succesfully load the functions even though thedlopen('libEGL.so')call returns a null handle, indicating failure.Additionally, @mrobinson found this issue which indicates other bindings like
khronos-eglloadlibEGL.so.1instead oflibEGL.so.This issue is to decide if it is a good idea to do the same in surfman. I don't have expertise in EGL, so I am not sure if we still need a fallback to loading
libEGL.soiflibEGL.so.1fails to load, like khronos-egl does. I have tested with a patched surfman that loadinglibEGL.so.1does indeed fix theegl function was not loadedissues and Servo continues to work.