If you extract lib/incoming/ld-2.39.so from http://ftp.slackware.com/pub/slackwa....39-i586-1.txz and copy it to /lib/ld-2.39.so, will it be broken again? That would be a 32-bit dynamic linker built by Pat on 32-bit Slackware using a 32-bit toolchain.

1 members found this post helpful.

haha good idea to try that and the answer is yes. After copying ld-2.39.so from aaa_glibc-solibs-2.39-i586-1.txz it is broken again with the nvidia GLX, but Mesa GLX is still working OK using __GLX_VENDOR_LIBRARY_NAME=mesa /usr/bin/32/glxinfo.

I have rebuilt my binutils-2.41 now with all slackware patches, including the older version of the readelf patch. And rebuilt glibc-2.39 again. Everything is working fine with that combination. It is only when adding binutils-2.42 things go wrong.

edit: I forgot that I had copied a bad ld-2.39.so over and wondered why steam was suddenly crashing again.. oops.

This is weird. Did arch use binutils 2.42? I posted the nvidia forum thread (since it contains a link back here) to the gamingonlinux discord. Lot of people hang out there, and someone might have an insight into what Arch is doing that we aren't.

ETA: seems like most there are running AMD. :/

So maybe it is broken on arch, but since they all use AMD no one noticed
But yes, arch updated to binutils 2.42 5 days ago, and then it was rebuilt 3 days ago after the glibc-2.39 release: https://gitlab.archlinux.org/archlin...e46bd0b26fd572 so the arch release of glibc-2.39 must have been built using binutils 2.42.

Running Steam with __GLX_VENDOR_LIBRARY_NAME=mesa doesn't appear to have any negative consequences for the time being. (At least on the games I've been playing lately.) Probably not a great long-term fix, though.

Yes, I did wonder about that. It doesn't matter if steam is run without acceleration, but would this env var also get passed through to 64-bit games?

I was just going to test it by starting cs2.. but that uses vulkan anyway, not GLX
But euro truck simulator uses OpenGL, and when starting steam with __GLX_VENDOR_LIBRARY_NAME=mesa that is unplayable - so the vendor override does get passed to the games launched by steam.

So the DEBUGGER option would be better?

Yes I think so. The fastest DEBUGGER option seems to be
then "run" at the gdb prompt.
I noticed that when running glxinfo in gdb it runs at almost normal speed, but running with strace it runs very slowly.

1 members found this post helpful.

One person (Arch, nvidia) just updated tonight, and no issues. So I don't think it's an nvidia problem? More like a Slackware problem?

1 members found this post helpful.

https://github.com/ValveSoftware/ste...x/issues/10465 Oh hey! Looks like someone else is having the same problem, too! I'll weigh in.

2 members found this post helpful.

It looks like they have a different issue because their steam just freezes instead of failing to start at all.
I have been using my glibc-2.39 compiled with binutils-2.41 and that's been fine, so don't need any DEBUGGER stuff
When a new nvidia driver is released I was going to test again with the normal compat32 glibc.
I have also been careful not to update binutils to 2.42, but I guess that shouldn't matter as long as I don't need to recompile glibc.

1 members found this post helpful.

You know, on the one hand, I realize bugs like this take time to chase down. I also realize that I was thinking about going with AMD for my next video card, because the price for benchmarks was better than what I could afford with an nvidia card. But it's kind of frustrating that it feels like I don't have much of a choice between this bug, the framebuffer bug (that's been a thing for a year and may or may not be fixed on older cards), and the eternal pissing contest between kernel devs and nvidia devs. (Granted, the kernel devs do have a point, but it's tiresome from our standpoint, too.) Intel, sure, is a contender these days for normal usage, but if you game, you really don't have much of a choice. :/

I have used nvidia for years, but also wanted to try an AMD card this time because a lot of people seemed more happy with them than nvidia now. But my friend gave me her RTX3060 so I didn't need to buy a new card yet. I was slightly disappointed that I don't get to test a new AMD

Problem still exists with 550.40.07 and kernel 6.6.16. (Although I didn't have to patch the drivers, so yay? One problem fixed?) The drivers date from January 24, so I don't think the problem with OpenGL would've been addressed then.

1 members found this post helpful.

I also saw the kernel had been updated to 6.6.16 so decided to give it a try just now with new binutils and recompiled glibc with them, but still not working. So it really does look like a binutils-2.42 compatibility thing.