* [ISSUE] libGL: consider devirtualizing
@ 2020-12-19 22:45 st3r4g
2020-12-19 22:50 ` abenson
` (20 more replies)
0 siblings, 21 replies; 22+ messages in thread
From: st3r4g @ 2020-12-19 22:45 UTC (permalink / raw)
To: ml
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
@ 2020-12-19 22:50 ` abenson
2021-01-20 20:32 ` ericonr
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: abenson @ 2020-12-19 22:50 UTC (permalink / raw)
To: ml
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
2020-12-19 22:50 ` abenson
@ 2021-01-20 20:32 ` ericonr
2021-01-20 20:32 ` ericonr
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-20 20:32 UTC (permalink / raw)
To: ml
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
2020-12-19 22:50 ` abenson
2021-01-20 20:32 ` ericonr
@ 2021-01-20 20:32 ` ericonr
2021-01-20 21:33 ` st3r4g
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-20 20:32 UTC (permalink / raw)
To: ml
[-- 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 :/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (2 preceding siblings ...)
2021-01-20 20:32 ` ericonr
@ 2021-01-20 21:33 ` st3r4g
2021-01-20 21:36 ` ericonr
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: st3r4g @ 2021-01-20 21:33 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (3 preceding siblings ...)
2021-01-20 21:33 ` st3r4g
@ 2021-01-20 21:36 ` ericonr
2021-01-20 21:45 ` st3r4g
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-20 21:36 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (4 preceding siblings ...)
2021-01-20 21:36 ` ericonr
@ 2021-01-20 21:45 ` st3r4g
2021-01-20 21:46 ` st3r4g
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: st3r4g @ 2021-01-20 21:45 UTC (permalink / raw)
To: ml
[-- 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...
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (5 preceding siblings ...)
2021-01-20 21:45 ` st3r4g
@ 2021-01-20 21:46 ` st3r4g
2021-01-20 21:47 ` st3r4g
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: st3r4g @ 2021-01-20 21:46 UTC (permalink / raw)
To: ml
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (6 preceding siblings ...)
2021-01-20 21:46 ` st3r4g
@ 2021-01-20 21:47 ` st3r4g
2021-01-20 21:47 ` st3r4g
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: st3r4g @ 2021-01-20 21:47 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (7 preceding siblings ...)
2021-01-20 21:47 ` st3r4g
@ 2021-01-20 21:47 ` st3r4g
2021-01-20 21:49 ` st3r4g
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: st3r4g @ 2021-01-20 21:47 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (8 preceding siblings ...)
2021-01-20 21:47 ` st3r4g
@ 2021-01-20 21:49 ` st3r4g
2021-01-20 21:49 ` ericonr
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: st3r4g @ 2021-01-20 21:49 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (9 preceding siblings ...)
2021-01-20 21:49 ` st3r4g
@ 2021-01-20 21:49 ` ericonr
2021-01-20 21:50 ` ahesford
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-20 21:49 UTC (permalink / raw)
To: ml
[-- 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?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (10 preceding siblings ...)
2021-01-20 21:49 ` ericonr
@ 2021-01-20 21:50 ` ahesford
2021-01-20 21:56 ` ericonr
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ahesford @ 2021-01-20 21:50 UTC (permalink / raw)
To: ml
[-- 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.)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (11 preceding siblings ...)
2021-01-20 21:50 ` ahesford
@ 2021-01-20 21:56 ` ericonr
2021-01-21 14:48 ` ahesford
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-20 21:56 UTC (permalink / raw)
To: ml
[-- 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?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (12 preceding siblings ...)
2021-01-20 21:56 ` ericonr
@ 2021-01-21 14:48 ` ahesford
2021-01-21 14:55 ` ericonr
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ahesford @ 2021-01-21 14:48 UTC (permalink / raw)
To: ml
[-- 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?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (13 preceding siblings ...)
2021-01-21 14:48 ` ahesford
@ 2021-01-21 14:55 ` ericonr
2021-01-21 15:32 ` ericonr
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-21 14:55 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (14 preceding siblings ...)
2021-01-21 14:55 ` ericonr
@ 2021-01-21 15:32 ` ericonr
2021-01-21 15:49 ` ahesford
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-21 15:32 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (15 preceding siblings ...)
2021-01-21 15:32 ` ericonr
@ 2021-01-21 15:49 ` ahesford
2021-01-21 16:17 ` ericonr
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ahesford @ 2021-01-21 15:49 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (16 preceding siblings ...)
2021-01-21 15:49 ` ahesford
@ 2021-01-21 16:17 ` ericonr
2021-01-21 18:00 ` ahesford
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: ericonr @ 2021-01-21 16:17 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (17 preceding siblings ...)
2021-01-21 16:17 ` ericonr
@ 2021-01-21 18:00 ` ahesford
2022-05-01 2:14 ` github-actions
2022-05-16 2:07 ` [ISSUE] [CLOSED] " github-actions
20 siblings, 0 replies; 22+ messages in thread
From: ahesford @ 2021-01-21 18:00 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (18 preceding siblings ...)
2021-01-21 18:00 ` ahesford
@ 2022-05-01 2:14 ` github-actions
2022-05-16 2:07 ` [ISSUE] [CLOSED] " github-actions
20 siblings, 0 replies; 22+ messages in thread
From: github-actions @ 2022-05-01 2:14 UTC (permalink / raw)
To: ml
[-- 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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ISSUE] [CLOSED] libGL: consider devirtualizing
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
` (19 preceding siblings ...)
2022-05-01 2:14 ` github-actions
@ 2022-05-16 2:07 ` github-actions
20 siblings, 0 replies; 22+ messages in thread
From: github-actions @ 2022-05-16 2:07 UTC (permalink / raw)
To: ml
[-- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2022-05-16 2:07 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-19 22:45 [ISSUE] libGL: consider devirtualizing st3r4g
2020-12-19 22:50 ` abenson
2021-01-20 20:32 ` ericonr
2021-01-20 20:32 ` ericonr
2021-01-20 21:33 ` st3r4g
2021-01-20 21:36 ` ericonr
2021-01-20 21:45 ` st3r4g
2021-01-20 21:46 ` st3r4g
2021-01-20 21:47 ` st3r4g
2021-01-20 21:47 ` st3r4g
2021-01-20 21:49 ` st3r4g
2021-01-20 21:49 ` ericonr
2021-01-20 21:50 ` ahesford
2021-01-20 21:56 ` ericonr
2021-01-21 14:48 ` ahesford
2021-01-21 14:55 ` ericonr
2021-01-21 15:32 ` ericonr
2021-01-21 15:49 ` ahesford
2021-01-21 16:17 ` ericonr
2021-01-21 18:00 ` ahesford
2022-05-01 2:14 ` github-actions
2022-05-16 2:07 ` [ISSUE] [CLOSED] " github-actions
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).