Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
nvidia-drivers-340.108
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Brumi-2021
n00b
n00b


Joined: 17 Oct 2021
Posts: 7

PostPosted: Sun Aug 07, 2022 8:21 am    Post subject: nvidia-drivers-340.108 Reply with quote

Hi Shibotto and Ionen, and Randy Andy ,

Recently I opened a thread about general Opengl problems , with an old recycled laptop, with GPU : NVIDIA Geforce 9300M GS .
https://forums.gentoo.org/viewtopic-p-8735719.html#8735719

But after checking re recently , sudo dsmesg output , I think it is directly related to all this previous threat . (apologize for it)

I could read that in that link , I can find my needed NVIDIA driver (nvidia-drivers-340.108-r4.ebuild) ,
https://github.com/achurch/noglvnd


I already masked the , >=x11-drivers/nvidia-drivers-390.154 (to block the supported current gentoo NVIDIA drivers)

[TXT] nvidia-drivers-390.1..> 12-Jun-2022 19:10 14K
[TXT] nvidia-drivers-390.1..> 02-Aug-2022 20:40 14K
[TXT] nvidia-drivers-470.1..> 12-Jun-2022 19:10 15K
[TXT] nvidia-drivers-470.1..> 02-Aug-2022 20:40 15K
[TXT] nvidia-drivers-510.7..> 12-Jun-2022 19:10 15K
[TXT] nvidia-drivers-510.8..> 02-Aug-2022 20:40 15K
[TXT] nvidia-drivers-515.4..> 21-Jul-2022 08:10 17K
[TXT] nvidia-drivers-515.5..> 28-Jun-2022 19:40 17K
[TXT] nvidia-drivers-515.6..> 02-Aug-2022 20:40 17K


But I am not sure , the commands that I need to do
for installing the old nvidia-drivers-340.108-r4 ,
and to integrate it correctly to the my kernel version , inux-5.18.13-pentoo

I could also read on above posts, that shiboto created and excellent new nvidia legacy 340 repo
https://gitlab.com/shibotto/nvidia-legacy
I read the instructions , and seems clear , but I think it would not work with my kernel linux 5.18. 13 .

Congratulations for your great job and strong support to the community!

Any help or guide will be highly appreciated,
Cheers,
Back to top
View user's profile Send private message
rogge
Tux's lil' helper
Tux's lil' helper


Joined: 13 Oct 2006
Posts: 132
Location: Erfurt

PostPosted: Thu Mar 16, 2023 9:03 am    Post subject: Reply with quote

Here your'll find patches for newer Kernels:

https://aur.archlinux.org/packages/nvidia-340xx
Back to top
View user's profile Send private message
rogge
Tux's lil' helper
Tux's lil' helper


Joined: 13 Oct 2006
Posts: 132
Location: Erfurt

PostPosted: Thu Mar 16, 2023 10:25 pm    Post subject: Reply with quote

Hello again,

I tried to compile the uptodate nvidia-kmod for Kernel 5.15.94, but it failed, again and again and I really don't know why.

Quote:
{ echo /var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/nvidia.ko; :; } | awk '!x[$0]++' - > /var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/modules.order
sh ./scripts/modules-check.sh /var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/modules.order
make -f ./scripts/Makefile.modpost
sed 's/\.ko$/\.o/' /var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/modules.order | scripts/mod/modpost -o /var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/Module.symvers -e -i Module.symvers -T -
ERROR: modpost: "agp_backend_release" [/var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/nvidia.ko] undefined!
ERROR: modpost: "agp_copy_info" [/var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/nvidia.ko] undefined!
ERROR: modpost: "agp_unbind_memory" [/var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/nvidia.ko] undefined!
ERROR: modpost: "agp_free_memory" [/var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/nvidia.ko] undefined!
ERROR: modpost: "agp_backend_acquire" [/var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/nvidia.ko] undefined!
ERROR: modpost: "agp_find_bridge" [/var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/nvidia.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:133: /var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/Module.symvers] Error 1
make[2]: *** Deleting file '/var/tmp/portage/x11-drivers/nvidia-kmod-340.108/work/kernel/Module.symvers'
make[1]: *** [Makefile:1818: modules] Error 2
make[1]: Leaving directory '/usr/src/linux-5.15.94-gentoo'
NVIDIA: left KBUILD.
nvidia.ko failed to build!


Please tell me, if you need some more information about this case.
Back to top
View user's profile Send private message
Mistwolf
Apprentice
Apprentice


Joined: 07 Mar 2007
Posts: 189
Location: Edmonton, AB

PostPosted: Tue Mar 21, 2023 9:58 pm    Post subject: Reply with quote

Known issue, see here: https://gitlab.com/shibotto/nvidia-legacy/-/issues/2
Back to top
View user's profile Send private message
rogge
Tux's lil' helper
Tux's lil' helper


Joined: 13 Oct 2006
Posts: 132
Location: Erfurt

PostPosted: Thu Mar 23, 2023 11:25 am    Post subject: Reply with quote

Mistwolf wrote:
Known issue, see here: https://gitlab.com/shibotto/nvidia-legacy/-/issues/2


Thanks a lot! I was really wondering, because I got the same error with 5.15.102 and the downgraded 5.10.174 and my FX 3800 is connected via pciee. So actually no need for AGP.
Back to top
View user's profile Send private message
nuku97
n00b
n00b


Joined: 14 Apr 2023
Posts: 5

PostPosted: Fri Apr 14, 2023 5:47 am    Post subject: QT applications segfault with nvidia-driver 340 Reply with quote

Hallo everyone,

I use the driver x11-drivers/nvidia-drivers-340.108-r101:0/340::nvidia-legacy on my old notebook with Nvidia Quattro NVS 160M graphics card, because the OpelnGL performance of open source Nouveau for this card is really bad in games.

I didn't really use my notebook during the last 1,5 years but kept updating it regulary, to have it ready for use whenever needed. Now I had to use it again but unfortunately noticed a problem related to the graphics driver, but don't know exactly when or with which package update this problem was introduced:

When using the nvidia-driver above, most QT/KDE application crash with a segmentation fault, dmesg reporting something like this:

Code:
[  827.938059] konsole[3683]: segfault at 0 ip 0000000000000000 sp 00007ffcd745b928 error 14 in konsole[55b9167e0000+4000]
[  827.938072] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.


However, I can start the QT application when running it with command:
Code:
LD_PRELOAD=/usr/lib64/libGL.so konsole


As far as I understand, that way, the libGL.so from Mesa/libglvnd will be used instead of nvidia's drivers one.

I googled and found a few threads from somebody else reporting this problem in various forums, but never a solution.

Previously all applications worked fine with the legacy nvidia driver.

There seems some kind of explanation at this thread:

https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1894504.html

However, I have no idea how to fix my system now in order to be able to run games with the Nvidia driver while using KDE/QT apps at the same time without the preload command.

Anyone else having these issues and a solution how to run a KDE desktop with this driver?

Thanks
Florian


Some more discussions I found about this:
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1895487.html
https://forums.debian.net/viewtopic.php?t=153892
https://forums.developer.nvidia.com/t/qt-5-15-4-and-upper-nvidia-driver-340-108-segmentation-fault-of-all-qt-soft/242956
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22626

PostPosted: Fri Apr 14, 2023 2:46 pm    Post subject: Reply with quote

As I read that thread, the solution is that you need to use libglvnd, rather than directly loading libGL.so from nvidia-drivers. Is your notebook unable to use any newer nVidia drivers than the 340 series? Remaining on such an old series is likely to cause you more problems as time passes.
Back to top
View user's profile Send private message
logrusx
Advocate
Advocate


Joined: 22 Feb 2018
Posts: 2407

PostPosted: Fri Apr 14, 2023 4:03 pm    Post subject: Reply with quote

Hu wrote:
Is your notebook unable to use any newer nVidia drivers than the 340 series?


If somebody ends up here, that's surely the case.

nuku97 I hate to say it, but you either write a wrapper library or move on. I guess if writing a wrapper library was simple, someone should have done it alreday, so...

Best Regards,
Georgi
Back to top
View user's profile Send private message
nuku97
n00b
n00b


Joined: 14 Apr 2023
Posts: 5

PostPosted: Sun Apr 16, 2023 12:31 pm    Post subject: Reply with quote

Hi all,

thanks for your responses.

Yes, this driver is unfortunately the last driver for my notebook's Nvidia Quatro NVS 160M card. After all, the notebook (Dell E6400) is from 2009... and yes, I already expected this trouble with the closed source driver. Still, the notebook is good enough for my use cases (used only a few weeks per year when visiting parents or parents in law), while my daily driver is now a powerful desktop with - of course - an AMD Radeon card and open source drivers ;-)

But back to the topic, in case somebody is interested:

I spend a few more hours and changed the overlay from nvidia-legacy to noglvnd (https://github.com/achurch/noglvnd), which was also mentioned somewhere above in this thread, getting rid of libglvnd and restoring the old "eselect opengl" behaviour. Of course I used emerge and revdep-rebuild to rebuild all packages with changed USE flags and library deps. But still: the QT/KDE apps crash just like before.

So this seems not (just) to be a problem with libglvnd, but maybe a problem with QT. In some other forum posts on the internet, somebody writes that this problem with the nvidia-driver occurs since Qt 5.15.4. Looking at the changelogs of the portage tree and comparing them to the last time I was really using the notebook about 1,5 years ago, indeed the QT version was lower than this at that time. I tried to downgrade QT but quickly gave up due to dependencies of latest stable KDE packages. And I don't think it makes sense to invest much more time and downgrade also all the KDE packages etc. Also, I tried to compile all kde-*/* and dev-qt/* with USE=-opengl, to no success.

So, my conclusion:
- for now, I will either use Nouveau with KDE for productivity or Nvidia-drivers with ICEWM for "gaming". Might try another lightweight DE without QT like LxDE to replace KDE....
- will continue to watch this thread, maybe someone comes up with a solution after all, who knows...
- in case I will buy a new notebook, I will try to grab one with a Radeon....

Have a nice day!
Florian
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22626

PostPosted: Sun Apr 16, 2023 4:37 pm    Post subject: Reply with quote

If you want to pursue this further, understanding the exact nature of the crash might be helpful to know which component(s) are at fault. We would want to see the full backtrace, with symbols. Register context may or may not help.
Back to top
View user's profile Send private message
Geneslaf
n00b
n00b


Joined: 07 Jul 2014
Posts: 10

PostPosted: Sun May 28, 2023 1:44 pm    Post subject: Reply with quote

nuku97 wrote:

- will continue to watch this thread, maybe someone comes up with a solution after all, who knows...


May not be a comprehensive solution but in my case ffmpeg and nvidia-settings were segmentation faulting however if I preload /lib64/libpthread.so.0 they run OK.

Code:

$ /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
Segmentation fault
$ LD_PRELOAD=/lib64/libpthread.so.0 /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
$


Mark
Back to top
View user's profile Send private message
JanR
Tux's lil' helper
Tux's lil' helper


Joined: 21 Jan 2007
Posts: 78

PostPosted: Mon Jun 19, 2023 8:01 pm    Post subject: Reply with quote

Quote:

May not be a comprehensive solution but in my case ffmpeg and nvidia-settings were segmentation faulting however if I preload /lib64/libpthread.so.0 they run OK.


Thank you for that idea!

It solved my problem (crashes with many QT-programs and nvidia 340 driver from overlay) too.

Problem description:

https://forums.gentoo.org/viewtopic-p-8792666.html#8792666

Interesting observation: I get no crashes when starting in gdb or strace. Therefore, I guess a timing problem with these libraries. It seems that preloading the pthread library has the same effect.
Back to top
View user's profile Send private message
Geneslaf
n00b
n00b


Joined: 07 Jul 2014
Posts: 10

PostPosted: Tue Jun 20, 2023 7:10 pm    Post subject: Reply with quote

JanR wrote:
Quote:

May not be a comprehensive solution but in my case ffmpeg and nvidia-settings were segmentation faulting however if I preload /lib64/libpthread.so.0 they run OK.

Thank you for that idea!

It solved my problem (crashes with many QT-programs and nvidia 340 driver from overlay) too.

Interesting observation: I get no crashes when starting in gdb or strace. Therefore, I guess a timing problem with these libraries. It seems that preloading the pthread library has the same effect.

Thank you for confirming that is solves the QT problems as well - I don't run anything with QT so was wondering if it was the same underlying problem.

As far as I can tell the problem has nothing to do with timings or memory layout, its caused by what the nvidia code is doing. In my case with ffmpeg the crash was caused by a call of pthread_create. I discovered that libGL.so is inserting a wrapper around the pthread_create call but if libpthread.so is not loaded then it fails to fill in the address for the call to the real pthread_create. The nvidia libraries are supplied as binaries and were compiled in 2019 before the stuff in libpthread.so was moved into libc.so so it sort of makes sense that it does not look for the real pthread_create address if libpthread.so is not loaded. The fix had nothing to do with memory layout, its because something inside libGL.so is done only if something called libpthread.so is loaded.
Code:

$ /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
Segmentation fault
$ gcc -shared -o libpthread.so /dev/null
$ LD_PRELOAD=${PWD}/libpthread.so /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
$ mv libpthread.so libfoobar.so
$ LD_PRELOAD=${PWD}/libfoobar.so /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
$ Segmentation fault

or using a non empty library
Code:

$ ldd /usr/bin/ffmpeg | grep libncurses
$ cp /lib64/libncurses.so.6 .
$ LD_PRELOAD=${PWD}/libncurses.so.6 /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
Segmentation fault
$ mv libncurses.so.6 libpthread.so.6
$ LD_PRELOAD=${PWD}/libpthread.so.6 /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
$

This was not a problem in the past because cairo linked in libEGL.so which would pull in libpthread.so but x11-libs/cairo-1.17.6-r1 removed opengl support so did not need libEGL.so.

When run in gdb no wrapper is inserted around pthread_create so all is OK, I suspect that it detects the tracing using TracerPid in /proc/self/status
Code:

$ strings -a /usr/lib64/opengl/nvidia/lib/libGL.so.340.108  | grep -P "TracerPid|libpthread|status"
/proc/self/status
libpthread.so.0
;/proc/self/status
TracerPid:
libpthread.so

and then hides what it would do when not traced, the same would be true for strace - it is a proprietary driver.

Currently I am using wrapper scripts for the preload but using patchelf to add libpthread.so as a dependancy to libGL.so may be better approach i.e.
Code:

$ cp /usr/lib64/opengl/nvidia/lib/libGL.so.340.108 .
$ LD_PRELOAD=${PWD}/libGL.so.340.108 /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
Segmentation fault
$ patchelf --add-needed libpthread.so.0 libGL.so.340.108
$ LD_PRELOAD=${PWD}/libGL.so.340.108 /usr/bin/ffmpeg -hide_banner -nostats -loglevel error -i from.mp3 -y to.mp3
$


Mark
Back to top
View user's profile Send private message
molletts
Tux's lil' helper
Tux's lil' helper


Joined: 16 Feb 2013
Posts: 129

PostPosted: Mon Jun 26, 2023 5:11 pm    Post subject: Reply with quote

Geneslaf wrote:

Currently I am using wrapper scripts for the preload but using patchelf to add libpthread.so as a dependancy to libGL.so may be better approach i.e.
Code:
...
$ patchelf --add-needed libpthread.so.0 libGL.so.340.108
...



Thanks for that! I've been able to switch my #2 PC (at my parents' place) back from Nouveau to the Nvidia 340.108 driver. Nouveau was good enough most of the time, with manual reclocking when needed, but the lack of GL threading caused problems for some applications (most recently causing SDDM to hang at a black screen and log DMA_PUSHER errors in dmesg, requiring me to restart it from the text console one or more times) and its memory management wasn't great - the card would run out of VRAM after gaming for a while, requiring a reboot to recover.

KDE (and everything else) now runs perfectly and I can, hopefully, nurse a little more life out of my perfectly-good fully-working GTX260. I guess eventually I'll upgrade my main PC to a Radeon, move the GTX460 down from it and repeat the process until that either dies or the 390.x drivers become impossible to maintain.

I've used a portage post-install hook to automatically patch both the 64- and 32-bit libGL.so.340.108 in case x11-drivers/nvidia-drivers gets rebuilt for any reason.
Back to top
View user's profile Send private message
nuku97
n00b
n00b


Joined: 14 Apr 2023
Posts: 5

PostPosted: Wed Jul 12, 2023 9:28 pm    Post subject: Reply with quote

Thank you for sharing the patchelf command! This also worked for me and my KDE desktop runs fine again on this old notebook from 2009!
[/code]
Back to top
View user's profile Send private message
Shibotto
Apprentice
Apprentice


Joined: 19 Jun 2015
Posts: 157
Location: CET/CEST

PostPosted: Tue Dec 26, 2023 11:08 pm    Post subject: Reply with quote

Long time no see folks, let me cut straight to the important stuff:

  • I've been using and testing the AUR patches for a couple of weeks and everything seems OK with 5.10, 5.15, 6.1 and 6.6. I'm dropping the kernel config checks though, because I've never actually checked them (I'm a -bin user) and they are most likely wrong/obsolete. If anyone can make a comprehensive list spanning at least the 4 kernel versions mentioned above, I will gladly include it.

  • Thank you so much for the patchelf solution, I will do that directly in the ebuild.

ETA this week, barring unforeseen circumstances.


↓↓↓ Chatting time (aka you don't have to read this) ↓↓↓

So, it's been 2 years. Did my old Nvidia hardware die? Was I too busy to take care of this overlay? None of the above, I just... didn't strictly need to. After all my goal from the very beginning was to set it up in a way that it would very hardly ever conflict with whatever might happen in Gentoo, so I sat comfortably on 5.15 and kept upgrading the rest of the distro without a worry in the world. And that's the end of the happy, "mission accomplished" part of this story.

At the same time, I've been very disheartened by the maintenance struggle kernel developers are facing with LTS versions. LTS' are vital for us, because any kernel at any given time could be the end of the line, the last one which this relic of a driver could be reasonably adapted to. So when I look at the right column of the longterm table and see a pile of "Dec, 2026"... why should I even bother with newer kernels?

What changed then? For starters, linux-mod.eclass got deprecated. It will probably still be there for quite some time, but I don't like sitting on a time bomb (well, not another one) waiting for portage to fail on me. We have a new eclass of course and it even has a quick migration guide to make the transition super simple. As always, many, many thanks to Ionen for the hard work. The other reason is that since Gentoo only supports < 3 years old kernels (except for vanilla-sources), as a gentoo-kernel-bin user I only have 1 year left of 5.15. I'm already missing when "Dec, 2026" sounded bad. So now was a good time to get this moving again.

Oh, and the Qt issue. I can't make any excuses here: I've been aware of the problem since around mid 2022, but because I didn't know of a proper solution I've never brought it up. I've spent a lot of time on that though. First I tried debugging, but what I got didn't ring any bell at the moment. So I did the only next obvious thing: install another Gentoo and upgrade it until the problem shows up again. Ionen, if you remember seeing me hunting for a 4 months old or so stage3 on IRC around last December, now you know what I was doing :P . It took a long time, but if I remember correctly the trigger on my system was libpcre2 which stopped linking directly to libpthread, the only component which was bringing libpthread in the chain of dependencies of every Qt programs. After that the LD_PRELOAD workaround was obvious, but that's as far as my knowledge of libraries goes. I didn't know about patchelf and I still really don't; the sad thing is that if I mentioned this here I would have been able to fix this months ago. My bad.
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3417
Location: Canada

PostPosted: Wed Dec 27, 2023 1:55 am    Post subject: Reply with quote

Well, that 3 year limit on LTS kernels from gentoo is a bummer. When you build a server, it's lifetime is usually more than 3 years, and during its life you do not what to play with kernel upgrades much. It is funny if my older nvidia-340 computer will get the newest kernel among all my machines as the result (they all stuck at 4.19)

Last edited by dmpogo on Fri Nov 08, 2024 6:20 pm; edited 2 times in total
Back to top
View user's profile Send private message
nuku97
n00b
n00b


Joined: 14 Apr 2023
Posts: 5

PostPosted: Sat Sep 14, 2024 5:09 pm    Post subject: Reply with quote

Hallo everyone,

I have been using the ebuilds from the nvidia-legacy overlay without problems for the past 1,5 years.

After some system updates however, the OpenGL part of the nvidia driver doesn't work for me anymore. I don't know which update caused the problem. Also re-emerging nvidia-drivers and nvidia-kmod didn't solve the problem.

I can start a X11 session with IceWM without problems. But OpenGL programs like glxgears, steam, even "konsole" from KDE don't start anymore.

glxgears reports:
Code:

$ glxgears
Error: couldn't get an RGB, Double-buffered visual


I found out, that I can fix the problem when preloading /usr/lib64/nvidia/libGL.so, e.g. by running:
Code:

$ LD_PRELOAD=/usr/lib64/nvidia/libGL.so glxgears


This will definitly use the Nvidia driver, as also reported by glxinfo:
Code:

$  LD_PRELOAD=/usr/lib64/nvidia/libGL.so.340.108 glxinfo | grep "client glx vendor string"
client glx vendor string: NVIDIA Corporation


So it seems the system is using by default a different libGL.so, probably the one in /usr/lib64/libGL.so which is provided by media-libs/libglvnd-1.7.0

As far as I understand libglvnd is like a wrapper to switch between vendors.

For example, I can also successfully run:
Code:

$ __GLX_VENDOR_LIBRARY_NAME=mesa glxgears


and this will use libGL from Mesa, as can be confirmed with
Code:

$ __GLX_VENDOR_LIBRARY_NAME=mesa glxinfo | grep "client glx vendor string"
client glx vendor string: Mesa Project and SGI


So I assume my system is using the libglvnd with a wrong vendor or libglvnd is not aware of the available Nvidia driver. Trying to use "nvidia" vendor does not work:

Code:

$ __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig

$ __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears
Error: couldn't get an RGB, Double-buffered visual


So my question: How can I configure the system to use the libGL.so from nvidia by default? Is there a way to configure glvnd to use the file /usr/lib64/nvidia/libGL.so.340.108 ? Other suggestions? Maybe my updates broke a config file?

Thanks and best regards
Florian
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2852

PostPosted: Sat Sep 14, 2024 6:49 pm    Post subject: Reply with quote

The reason 340.xx was dropped from the tree earlier than it would have otherwise is because it does *not* support libglvnd, and that means __GLX_VENDOR_LIBRARY_NAME=nvidia cannot be used. 390.xx also only has partial support, but that still makes the situation better. Newer (still supported) branches instead do not support not using libglvnd, making it required.

340 legacy ebuild does three notable things, adjust LDPATH so applications do *not* use libglvnd even if installed, then adjust the Xorg module path (like 390 needs) to override the vendor neutral glx module, then tells Xorg to ignore ABI version incompatibility given the module is too old for modern Xorg and just been lucky that it still worked anyway.

aka from the ebuild:
Code:
      newenvd - "000nvidia" <<-EOF
         LDPATH="$( IFS=:; echo "${nvidia_ldpaths[*]}" )"
      EOF
(this is installed to /etc/env.d/000nvidia, and running "env-update", which portage does by default, should update /etc/ld.so.conf to contain the given path at the top and it will also have run ldconfig to update ld.so.cache, and so this tells applications to prioritize that libGL)

...and from nvidia.xorg-conf in filesdir
Code:
<snip>
   ModulePath "@LIBDIR@/nvidia/xorg"
EndSection
Section "ServerFlags"
   Option "IgnoreABI" "1"
EndSection
These mostly replicate what the old "eselect opengl" did, but by forcing by default instead.

As for why it broke for you, I don't know. Sounds like LDPATH is not working as intended for some reason if preload works, maybe another package has installed a LDPATH file for you and it results in wrong priorities or something.

On a side-note, some applications may be using libOpenGL rather than libGL, libOpenGL is a variant of libGL that does not use the X-only libGLX and nvidia 340 does not a provide that version (never tried but symlinking "could" potentially work). "glx"gears should still be using libGL though.

That aside, I do expect 340 to break entirely at some point that's likely not far, overall I can only suggest to consider moving on (either use nouveau even if not ideal, or replace hardware if nouveau is too terrible) given situation will just keep getting worse.
Back to top
View user's profile Send private message
nuku97
n00b
n00b


Joined: 14 Apr 2023
Posts: 5

PostPosted: Sun Sep 15, 2024 10:14 am    Post subject: Reply with quote

Ionen, thanks for the explanation regarding libglvnd.

For now I will live with the PRELOAD workaround or switch to nouveau. Maybe someone else will stumble upon the same problem, find a solution and post it here. The files you mentioned (xorg, env.d) are installed and X11 is using the nvidia driver, something just doesn't work with the GL applications anymore - after lots of updates since I really used the affected system. I probably won't be able to identify which update exactly broke the system.

So you are right, it would be wise to move on to newer hardware, this is a notebook from 2009. Because only rarely need, so I didn't feel like spending money for something new. But I might look for a cheap refurbished replacement :)

Thanks and have a nice day!
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3417
Location: Canada

PostPosted: Sun Sep 15, 2024 2:39 pm    Post subject: Reply with quote

I realized that I have not tried opengl programs on my nvidia-340 machine after upgrade. Did not logged into KDE yet, playing with FVWM instead. Which would be enough for me if push comes to shovel. Need to go and see !

Indeed it does not work without LD_PRELOAD


Last edited by dmpogo on Fri Nov 08, 2024 6:25 pm; edited 3 times in total
Back to top
View user's profile Send private message
Geneslaf
n00b
n00b


Joined: 07 Jul 2014
Posts: 10

PostPosted: Sun Sep 15, 2024 2:57 pm    Post subject: Reply with quote

nuku97 wrote:
Ionen, thanks for the explanation regarding libglvnd.

For now I will live with the PRELOAD workaround or switch to nouveau. Maybe someone else will stumble upon the same problem, find a solution and post it here. The files you mentioned (xorg, env.d) are installed and X11 is using the nvidia driver, something just doesn't work with the GL applications anymore - after lots of updates since I really used the affected system. I probably won't be able to identify which update exactly broke the system.

So you are right, it would be wise to move on to newer hardware, this is a notebook from 2009. Because only rarely need, so I didn't feel like spending money for something new. But I might look for a cheap refurbished replacement :)

Thanks and have a nice day!


Gentoo is patching x11-apps/mesa-progs-9.0.0 to use libOpenGL rather than libGL see https://github.com/gentoo/gentoo/blob/master/x11-apps/mesa-progs/files/9.0.0-Disable-things-we-don-t-want.patch.

I'm undoing that part of the patch using /etc/portage/patches with

Code:
--- a/meson.build       2024-08-13 19:24:50.717663000 +0100
+++ b/meson.build       2024-08-13 19:26:24.574663000 +0100
@@ -39,7 +39,7 @@
 dep_m = cc.find_library('m', required : false)
 dep_winmm = cc.find_library('winmm', required : false)
 
-dep_gl = dependency('opengl')
+dep_gl = dependency('gl')
 
 dep_epoll = dependency('epoll-shim', required : false)
 dep_gles1 = dependency('glesv1_cm', required : get_option('gles1'))
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3417
Location: Canada

PostPosted: Sun Sep 15, 2024 3:20 pm    Post subject: Reply with quote

it is not just mesa-progs, kde parts such as konsole also do not work, do they also use libOpenGL ?
Back to top
View user's profile Send private message
Ionen
Developer
Developer


Joined: 06 Dec 2018
Posts: 2852

PostPosted: Sun Sep 15, 2024 4:06 pm    Post subject: Reply with quote

Ah, hadn't noticed that patch for mesa-progs. In a glvnd world it's technically preferable to use libOpenGL, but that doesn't work out for the usage here. As I mentioned a libOpenGL -> libGL symlink may be worth trying, afaik libOpenGL is libGL just with a few things in less (not more, so afaik it "shouldn't" be missing anything).

dmpogo wrote:
it is not just mesa-progs, kde parts such as konsole also do not work, do they also use libOpenGL ?
Many cmake-built packages are going to use libOpenGL nowadays unless told otherwise given cmake's (upstream) GL modules handle that for them and I think(?) the default was flipped to GLVND at some point (many packages are explicitly requesting it either way given it's needed to allow a pure no-X11-libraries wayland-only build w/ GL). Qt6 also switched to cmake, and sure enough QtOpenGL is using it:
Code:
$ scanelf -n /usr/lib64/libQt6OpenGL.so.6
 TYPE   NEEDED FILE
ET_DYN libQt6Gui.so.6,libOpenGL.so.0,libQt6Core.so.6,libstdc++.so.6,libm.so.6,libc.so.6 /usr/lib64/libQt6OpenGL.so.6
(I assume qt5's wasn't, but I haven't checked)
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3417
Location: Canada

PostPosted: Sun Sep 15, 2024 5:33 pm    Post subject: Reply with quote

Ionen wrote:
Ah, hadn't noticed that patch for mesa-progs. In a glvnd world it's technically preferable to use libOpenGL, but that doesn't work out for the usage here. As I mentioned a libOpenGL -> libGL symlink may be worth trying, afaik libOpenGL is libGL just with a few things in less (not more, so afaik it "shouldn't" be missing anything).

dmpogo wrote:
it is not just mesa-progs, kde parts such as konsole also do not work, do they also use libOpenGL ?
Many cmake-built packages are going to use libOpenGL nowadays unless told otherwise given cmake's (upstream) GL modules handle that for them and I think(?) the default was flipped to GLVND at some point (many packages are explicitly requesting it either way given it's needed to allow a pure no-X11-libraries wayland-only build w/ GL). Qt6 also switched to cmake, and sure enough QtOpenGL is using it:
Code:
$ scanelf -n /usr/lib64/libQt6OpenGL.so.6
 TYPE   NEEDED FILE
ET_DYN libQt6Gui.so.6,libOpenGL.so.0,libQt6Core.so.6,libstdc++.so.6,libm.so.6,libc.so.6 /usr/lib64/libQt6OpenGL.so.6
(I assume qt5's wasn't, but I haven't checked)



it is interesting, just read 2016 discussion on libglvnd forum, about whether to maintain libOpenGL. So people argued that it will introduce confusion, but their voice did not find traction.

https://github.com/NVIDIA/libglvnd/issues/63

with conclusion
Quote:

evelikov commented on Feb 12, 2016
@kbrenneman so it seems that I cannot convince you that the "lets export some arbitrary list of symbols" design makes things a bit more confusing and fragile ? It'll be a shame if we have to do "The new^2 Linux OpenGL ABI" in a few years ... Hope that you'll be around joking about it over a few beers :)

Let's close this ticket.



And from the same thread, I wonder if that changed
Quote:

You can use any combination of libGL.so, libGLX.so, libOpenGL.so, and libGLES*.so in the same process and they all just work. That's also why libOpenGL.so is optional -- the functions that it exports are the same as the functions that you get from glXGetProcAddress or any of the others.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 4 of 5

 
Jump to:  
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