Re: libGL: consider devirtualizing

[ahesford <ahesford@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/27286#issuecomment-764832165

Comment:
I don't think this is really an issue for `rpi-userland`:
- The `libEGL.so` and `libGLESv2.so` shipped by `rpi-userland` have no versions. The only `shlib-requires` for `libEGL.so` in the `armv7l` repo are `ioquake3-rpi` and `libvlc`, both of which have always set `rpath`. Only `ioquake3-rpi` has an `shlib-requires` on `libGLESv2.so`. Having a glibc search path here doesn't solve any problems.
- There is a possibility that some packages `dlopen` an unversioned `libEGL.so` or `libGLESv2.so` but, in that case, those packages would be broken even against `libglvnd` without `libglvnd-devel`. Installing `rpi-userland` might allow these applications to work if `libglvnd-devel` weren't installed and the search path were modified. However, having *both* `rpi-userland` and `libglvnd-devel` installed could cause unexpected behavior. You might want the `rpi-userland` version but wind up with `libglvnd-devel`, or you might want `libglvnd` and wind up with `rpi-userland` just because you installed it for some other utility. (For me, the biggest feature of `rpi-userland` is its `vcgencmd` to query the VideoCore hardware and do things like flash RPi4 firmware. The OpenGL stuff isn't even relevant for me because I run the `aarch64` version which doesn't include these libraries.)

Given that `rpi-userland` has broader utility than providing vendor-specific OpenGL, and may be installed for that purpose; and given that trying to hook `rpi-userland` into everyday OpenGL workflows seems to be a corner case that probably isn't satisfactorily resolved even by an addition to the glibc linker path; I think we should leave `rpi-userland` as is and, if somebody reports some unexpected breakage, we can resume the discussion about the best fix.

This doesn't bear on the virtual `libGL` anyway, so de-virtualizing that library can proceed anyway.

Regarding `sunxi-mali`, I assume specific directories in `/etc/ld.so.conf` or its includes take precedence over the trusted locations like `/usr/lib`. That package installs versioned `libEGL.so.1` and `libGLESv2.so.2` which directly replace the `libglvnd` libraries, so modifying the linker path will work as expected in that case. I support that for `sunxi-mali` because the *only* value to `sunxi-mali` seems to be as a vendored OpenGL, so installing it can reasonably be expected to override the generic implementation.