[ISSUE] libGL: consider devirtualizing

[ISSUE] libGL: consider devirtualizing

[st3r4g]

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

New issue by st3r4g on void-packages repository

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

Description:
`libGL` and friends being virtual gives some [unexpected behaviour](https://www.reddit.com/r/voidlinux/comments/kgeyvf/opengl_no_longer_working_after_a_clean_install/). Two options:
1) fix virtual package selection in xbps (how? who?)
2) make things easier/saner by getting rid of vpkg where possible. After all, `libglvnd` exists exactly for this purpose, that is avoiding multiple conflicting libGL library files. Vendors should use the `libglvnd` mechanism.

Option 2 means:
- Current `libGL` providers have to be removed: `nvidia340` (EOL) and `sunxi-mali` (?)
- New proprietary GL implementations not using `libglvnd` won't be accepted.

Thoughts?

@q66 @abenson 

Re: libGL: consider devirtualizing

[abenson]

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

New comment by abenson on void-packages repository

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

Comment:
#27287 doing my part

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
Can now be done :D

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
Can now be done :D

Edit: ah no, sunxi-mali is a blocker :/

Re: libGL: consider devirtualizing

[st3r4g]

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

New comment by st3r4g on void-packages repository

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

Comment:
I wonder if we could install the conflicting libs into a separate location and do a loader hack via `/etc/ld.so.conf.d`. Should be the same result but without the possibility to accidentally have it pulled in.

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
`rpi-userland` is another provider of `libEGL`, btw. Such a trick would work for `sunxi-mali`, since it's glibc only, but I have no idea if graphics from `rpi-userland` work with musl.

Re: libGL: consider devirtualizing

[st3r4g]

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

New comment by st3r4g on void-packages repository

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

Comment:
> `rpi-userland` is another provider of `libEGL`, btw.

I just checked it and there is no `provides=` in the template and it seems doesn't even ship libEGL...

Re: libGL: consider devirtualizing

[st3r4g]

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

New comment by st3r4g on void-packages repository

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

Comment:
> `rpi-userland` is another provider of `libEGL`, btw.

I just checked it and there is no `provides=` in the template and it seems doesn't even ship libEGL...

EDIT: sorry armv7l does

Re: libGL: consider devirtualizing

[st3r4g]

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

New comment by st3r4g on void-packages repository

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

Comment:
> `rpi-userland` is another provider of `libEGL`, btw.

I just checked it and there is no `provides=` in the template and it seems doesn't even ship libEGL...

EDIT: sorry armv7l does. But it's in a different path.

Re: libGL: consider devirtualizing

[st3r4g]

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

New comment by st3r4g on void-packages repository

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

Comment:
> `rpi-userland` is another provider of `libEGL`, btw.

I just checked it and there is no `provides=` in the template ~~and it seems doesn't even ship libEGL...~~

EDIT: sorry armv7l does. But it's in a different path.

Re: libGL: consider devirtualizing

[st3r4g]

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

New comment by st3r4g on void-packages repository

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

Comment:
> `rpi-userland` is another provider of `libEGL`, btw.

I just checked it and there is no `provides=` in the template ~~and it seems doesn't even ship libEGL...~~

EDIT: sorry armv7l does. But it's in a different path. So `rpi-userland` is not a provider in the virtual package sense.

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
I just saw it in `shlib_provides`, maybe it doesn't matter here?

Re: libGL: consider devirtualizing

[ahesford]

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

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
rpath doesn't enable opengl libraries, though... maybe we can add something to the docs about using it (by configuring ld path) and be done with it?

Re: libGL: consider devirtualizing

[ahesford]

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

New comment by ahesford on void-packages repository

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

Comment:
Why does this not work for OpenGL?

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
Well, you use rpath to tell executables where to look for the libraries they want to use. Unless we fix all executables, they will look for `libGL` in `/usr/lib` (and therefore find libglvnd) and not in `/opt/whatever`. So you necessarily have to add the entry to your dynamic linker search path, either with a configuration file or `LD_LIBRARY_PATH`.

That said, given that you have already removed the file and no one's complained (yet - retropie-like users probably don't update all the time), we can probably just stop providing opengl related stuff with these libraries. `libglvnd` isn't big, so it doesn't really cost anything to have it installed when you don't need it.

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
Anyway, I still think we should move forward with devirtualizing libGL, it should make life better for everyone.

Re: libGL: consider devirtualizing

[ahesford]

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

New comment by ahesford on void-packages repository

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

Comment:
I see; the issue is that some people might want the `rpi-userland` to be a drop-in replacement for `libEGL` but obviously that requires runtime reconfiguration of the linker path.

This is not something we should really worry about. I think it's acceptable to tell people that they should reconfigure the linker on their own if they want to use this alternative.

Re: libGL: consider devirtualizing

[ericonr]

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

New comment by ericonr on void-packages repository

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

Comment:
> This is not something we should really worry about.

As far as I know, we changed the behavior of the package to make it something that you have to consciously configure. I have no idea if rpi-u's libEGL was actually fully functional with musl.

Maybe the ld.so.conf file could be shipped for glibc, at least? As suggested for sunxi-mali.

Re: libGL: consider devirtualizing

[ahesford]

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

Re: libGL: consider devirtualizing

[github-actions]

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

New comment by github-actions[bot] on void-packages repository

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

Comment:
Issues become stale 90 days after last activity and are closed 14 days after that.  If this issue is still relevant bump it or assign it.

Re: [ISSUE] [CLOSED] libGL: consider devirtualizing

[github-actions]

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

Closed issue by st3r4g on void-packages repository

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

Description:
`libGL` and friends being virtual gives some [unexpected behaviour](https://www.reddit.com/r/voidlinux/comments/kgeyvf/opengl_no_longer_working_after_a_clean_install/ggekz7b/?utm_source=reddit&utm_medium=web2x&context=3). Two options:
1) fix virtual package selection in xbps (how? who?)
2) make things easier/saner by getting rid of vpkg where possible. After all, `libglvnd` exists exactly for this purpose, that is avoiding multiple conflicting libGL library files. Vendors should use the `libglvnd` mechanism.

Option 2 means:
- Current `libGL` providers have to be removed: `nvidia340` (EOL) and `sunxi-mali` (?)
- New proprietary GL implementations not using `libglvnd` won't be accepted.

Thoughts?

@q66 @abenson