After the GStreamer update in Servo, the nightly binaries have been failing to launch on linux distros unless libegl1-mesa-dev or the equivalent package is installed in the runtime environment.
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. Because of this compile-time link, the dlsym calls are able to succesfully load the functions pointers even though the previous dlopen('libEGL.so') call returned a NULL handle indicating failure.
This patch makes surfman load libEGL.so.1 first and fallback to libEGL.so. If neither are available, then the initialization panics, unlike the previous behavior where we silently succeed if the binary has a link to the libEGL shared object with the symbols for functions that are used at the runtime.
mukilan
commented
8 months ago
After the GStreamer update in Servo, the nightly binaries have been failing to launch on linux distros unless
libegl1-mesa-devor the equivalent package is installed in the runtime environment.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. Because of this compile-time link, the dlsym calls are able to succesfully load the functions pointers even though the previous dlopen('libEGL.so') call returned a NULL handle indicating failure.
This patch makes surfman load
libEGL.so.1first and fallback tolibEGL.so. If neither are available, then the initialization panics, unlike the previous behavior where we silently succeed if the binary has a link to the libEGL shared object with the symbols for functions that are used at the runtime.Fixes #276.