Re: libGL: consider devirtualizing

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

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

New comment by ahesford on void-packages repository

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

Comment:
`rpi-userland` has an `shlib-provides` entry for `libEGL.so`, and it is installed in `/opt/vc/lib`. Before last week, `rpi-userland` installed an `ld.so.conf.d` file on glibc and a musl linker path configuration to direct the linker to these. I think this is a horrible idea, especially on musl, where that configuration is a single file that will clobber any user's configuration.

To fix this, I dropped the linker path configs and modified the few packages that depend on the `rpi-userland` libs to set rpaths on executables. (Several RPi packages already used the rpath, I just took it all the way.)

While I support installing these kinds of conflicting libraries somewhere else to allow them to coexist when only a few packages need them, I do *not* recommend attempting to modify linker search paths to accommodate them. Setting rpaths is a much better solution because it works as expected on musl and glibc.

(Using rpath can break new-style multilib if the path is static, which is why it's better to use variables like `$ORIGIN`... but `ld.so.conf` configuration will break these multilib setups anyway.)