| View previous topic :: View next topic |
| Author |
Message |
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3458
Location: Canada
|
 Posted: Sun Sep 15, 2024 5:51 pm Post subject: |
 |
|
BTW, for me glxgears and konsole work if I LD_PRELOAD startx
$ LD_PRELOAD=/usr/lib64/nvidia/libGL.so startx
I tried it with FVWM, glxgears and konsole launch all right. Not yet sure what is needed for full blown KDE desktop or some other Qt6 apps |
|
| Back to top |
|
 |
Shibotto
Apprentice
Joined: 19 Jun 2015
Posts: 157
Location: CET/CEST
|
| Posted: Wed Nov 06, 2024 10:30 pm Post subject: |
|
|
I posted something yesterday, but I realized I made a mistake and deleted it soon after. Hopefully no one saw it and I didn't break anything.
Hi everybody. I'm aware of the problem, I've been aware of it for quite a while actually (I think when dolphin-emu started linking against libOpenGL.so), but since it didn't impact me for any software I used, I saved it for future me to sort it out. Now I have the same problem with nextcloud-client which I rely upon a lot, so the time has come for me to think about a workaround.
As it has already been pointed out by Ionen, the libglvnd model (for our use case) entails two libraries which split the legacy libGL.so: libOpenGL.so for the actual OpenGL and libGLX.so for X11 related function. As far as I can see from my tests, our obsolete lib seems to have all the functions we need to be a drop-in replacement. That's why loading it with LD_PRELOAD makes the software work again. To avoid having to do this manually or even worse preloading it for every single software, I thought about the following: how about making 2 empty libraries that override libglvnd's libOpenGL.so and libGLX.so, link them to our libGL.so.340.108 and bring it to the chain this way? It's hacky, but I can't think of any cleaner way and it seems to get the job done. I haven't done anything in my overlay yet, but if you want to give it a try (assuming an amd64 environment) you can do:
| Code: | cd /usr/lib64/nvidia
gcc -shared -Wl,-soname,libOpenGL.so.0 -lGL -o libOpenGL.so.0 -xc /dev/null
gcc -shared -Wl,-soname,libGLX.so.0 -lGL -o libGLX.so.0 -xc /dev/null
ldconfig |
Since /usr/lib64/nvidia already has a higher priority because we need it for libGL.so, these fakes should be picked up automatically as well:
| Code: | [VPCS11E7E] shiba ~ > lddtree /usr/bin/glxinfo | grep GL
libGLX.so.0 => /usr/lib64/nvidia/libGLX.so.0
libGL.so.1 => /usr/lib64/nvidia/libGL.so.1
[VPCS11E7E] shiba ~ > glxinfo -B
name of display: :1
display: :1 screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 512 MB
Total available memory: 512 MB
Currently available dedicated video memory: 442 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 310M/PCIe/SSE2
OpenGL core profile version string: 3.3.0 NVIDIA 340.108
OpenGL core profile shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.3.0 NVIDIA 340.108
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL ES profile version string: OpenGL ES 2.0 NVIDIA 340.108 340.108
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.00 |
Seems good, doesn't it? Well, enters Qt6. No matter what, Qt6 libraries refused to load from /usr/lib64/nvidia/ and it took me a while to figure out why. It turned out that Qt by default set runpath when linking their libraries:
| Code: | [VPCS11E7E] shiba ~ > readelf -d /usr/lib64/libQt6Gui.so | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN] |
This is a problem because it adds the directory the Qt libs are in ($ORIGIN) to the directories that should be looked into for shared libraries, with a higher priority than anything specified in ld.so.conf, so libglvnd libraries will always be the first ones to be found out. If I manually remove runpath, everything works as expected:
| Code: | [VPCS11E7E] shiba ~ > libtree --max-depth 1 --path /usr/lib64/libQt6Gui.so
/usr/lib64/libQt6Gui.so
├── /usr/lib64/libEGL.so.1 [runpath]
├── /usr/lib64/libQt6Core.so.6 [runpath]
├── /usr/lib64/libz.so.1 [runpath]
├── /usr/lib64/libfreetype.so.6 [runpath]
├── /usr/lib64/libharfbuzz.so.0 [runpath]
├── /usr/lib64/libpng16.so.16 [runpath]
├── /usr/lib64/libOpenGL.so.0 [runpath]
├── /usr/lib64/libGLX.so.0 [runpath]
├── /usr/lib64/libxkbcommon.so.0 [runpath]
├── /usr/lib64/libQt6DBus.so.6 [runpath]
├── /usr/lib64/libglib-2.0.so.0 [runpath]
├── /usr/lib64/libX11.so.6 [runpath]
└── /usr/lib64/libfontconfig.so.1 [runpath]
[VPCS11E7E] root ~ > patchelf --remove-rpath /usr/lib64/libQt6Gui.so
[VPCS11E7E] shiba ~ > libtree --max-depth 1 --path /usr/lib64/libQt6Gui.so
/usr/lib64/libQt6Gui.so
├── /usr/lib64/nvidia/libEGL.so.1 [ld.so.conf]
├── /usr/lib64/nvidia/libGLX.so.0 [ld.so.conf]
├── /usr/lib64/nvidia/libOpenGL.so.0 [ld.so.conf]
├── /usr/lib64/libQt6Core.so.6 [ld.so.conf]
├── /usr/lib64/libharfbuzz.so.0 [ld.so.conf]
├── /usr/lib64/libpng16.so.16 [ld.so.conf]
├── /usr/lib64/libfreetype.so.6 [ld.so.conf]
├── /usr/lib64/libz.so.1 [ld.so.conf]
├── /usr/lib64/libxkbcommon.so.0 [ld.so.conf]
├── /usr/lib64/libQt6DBus.so.6 [ld.so.conf]
├── /usr/lib64/libglib-2.0.so.0 [ld.so.conf]
├── /usr/lib64/libX11.so.6 [ld.so.conf]
└── /usr/lib64/libfontconfig.so.1 [ld.so.conf] |
I cannot do this in my overlay though, I need Gentoo developers cooperation. Among their infinite list of options, Qt6 can also be configured with "QT_FEATURE_rpath=OFF" which will simply not write runpath at link time. Debian/Ubuntu and Fedora are already setting this and in my opinion with good reason: it makes sense for user built Qt, where you don't want your custom ones getting mixed with system libraries, not so much for system libraries themselves. Maybe it could be added to defaultcmakeargs in qt6-build.eclass? I can eventually open a bug report for this, although I'm not sure how not to phrase it like «could you please consider this linking option in a major toolkit that makes no difference for you, but it would be a great help for my security hazard overlay which I push to once a year?».
Anyway, if this is taken care of, we should be able to survive a few more years and I can move on to the kernel module. I'm sure nothing major happened on that front, like the removal of some legacy DRM infrastructure... right?  |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3458
Location: Canada
|
| Posted: Fri Nov 08, 2024 6:41 pm Post subject: |
|
|
| Shibotto wrote: | [b]
Seems good, doesn't it? Well, enters Qt6. No matter what, Qt6 libraries refused to load from /usr/lib64/nvidia/ and it took me a while to figure out why. It turned out that Qt by default set runpath when linking their libraries:
| Code: | [VPCS11E7E] shiba ~ > readelf -d /usr/lib64/libQt6Gui.so | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN] |
This is a problem because it adds the directory the Qt libs are in ($ORIGIN) to the directories that should be looked into for shared libraries, with a higher priority than anything specified in ld.so.conf: |
That by(pre)passing ld.so.conf sounds philosophically wrong, especially for a distribution where you are supposedly free to configure things yourself |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2884
|
| Posted: Fri Nov 08, 2024 10:35 pm Post subject: |
|
|
| dmpogo wrote: | | That by(pre)passing ld.so.conf sounds philosophically wrong, especially for a distribution where you are supposedly free to configure things yourself |
Plenty of things use rpath, esp. when libraries are installed in a special directory like /usr/lib sub-directory or /opt rather than add that directory to ld.so.conf, "respecting" ld.so.conf is not really a goal as long as the right libraries are loaded (ld.so.conf is largely distro-managed through env.d too, not really intended for users to change). There was even talk to use rpath to workaround time64 migration (I forget where we stand on that, recall that solution had issues), so it's a tool Gentoo will use when needed.
I guess rpath may also be a (rather minor) optimization? Won't have to search for libraries, even with ld.so.cache there's still overhead and Qt links a lot of libraries, so I'd have some resistance to change such a upstream default for a unsupported hack unless some other devs think we should or need it.
That aside, you are technically able to configure everything given Gentoo is a source based distro and there's nothing truly imposed as long as willing to deal with issues yourself (unless you want to use our prebuilt binpkgs that is), it can just be less intuitive by having to use e.g. MYCMAKEARGS="-Dsomeoption=OFF" through /etc/portage/package.env to pass arguments to dev-qt/qtbase:6 (which spare you from having to maintain modified ebuilds in an overlay).
Edit: I suppose some other hacky option could(?) be for the nvidia-legacy overlay to install its own "dummy" media-libs/libglvnd (with a high version number to come before gentoo's, maybe something like 9999.1.7.0 to still have the version) that installs headers, .pc, and such and symlinks to nvidia libraries rather than the real libglvnd. Would need no ldconfig tricks then, not to say if all packages will be happy to link with these, albeit failure may indicate that it won't run anyway. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3458
Location: Canada
|
| Posted: Sat Nov 09, 2024 8:54 pm Post subject: |
|
|
| Ionen wrote: | | dmpogo wrote: | | That by(pre)passing ld.so.conf sounds philosophically wrong, especially for a distribution where you are supposedly free to configure things yourself |
Plenty of things use rpath, esp. when libraries are installed in a special directory like /usr/lib sub-directory or /opt rather than add that directory to ld.so.conf, "respecting" ld.so.conf is not really a goal as long as the right libraries are loaded (ld.so.conf is largely distro-managed through env.d too, not really intended for users to change). There was even talk to use rpath to workaround time64 migration (I forget where we stand on that, recall that solution had issues), so it's a tool Gentoo will use when needed.
|
Sure, that is why I said 'philosophically'. Basically, it is in the modern trend of applications bypassing centralizied OS provided facilities and using their own mechanisms. Which, for me, is philosophically sad |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
