32-bit GLX (nvidia) not working after update, unless running with strace
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That package only contains header files, no binaries or libraries so won't need a compat32 version.
Everything else 32-bit seems to be fine, including vkcube, so I don't think it is a problem with multilib. Since libglvnd works OK with the Mesa 32-bit libs, it looks more like the nvidia libGLX isn't compatible with glibc-2.39 and so when libglvnd tries to dlopen it, it segfaults.
Can't see any mention of it on the nvidia forums though.
If you want to open a thread on the forums there, I'm game. Looks like Arch is on 2.39, but I don't know if any problems there have been reported? (Kind of waiting for multilib to sync, just to rule out any weirdness with stale libraries there.)
Just thought I would report in. I just tested this right now and I am having the same issue.
/usr/bin/32/glxgears
Code:
Segmentation fault
steam
Code:
# ------------------------------------ #
Slackware 32-bit:
Check the directory matching your Slackware version below http://www.slackware.com/~alien/slackbuilds/steamclient/deps/ . Install/upgrade any packages you find there (may be zero).
Slackware 64-bit:
You need to install multilib (see https://docs.slackware.com/slackware:multilib). Additionally, you need to install/upgrade any packages in the '<slackwareversion>/multilib' subdirectory of http://www.slackware.com/~alien/slackbuilds/steamclient/deps/ instead.
# ------------------------------------ #
steam.sh[3165]: Running Steam on slackware 15.0 64-bit
steam.sh[3165]: STEAM_RUNTIME is enabled automatically
setup.sh[3238]: Steam runtime environment up-to-date!
steam.sh[3165]: Steam client's requirements are satisfied
tid(3301) burning pthread_key_t == 0 so we never use it
[2024-02-04 10:54:24] Startup - updater built Jan 13 2024 00:51:43
[2024-02-04 10:54:24] Startup - Steam Client launched with: '/home/daedra/.local/share/Steam/ubuntu12_32/steam'
02/04 10:54:24 Init: Installing breakpad exception handler for appid(steam)/version(1705108172)/tid(3301)
crash_20240204105424_2.dmp[3304]: Uploading dump (out-of-process)
/tmp/dumps/crash_20240204105424_2.dmp
/home/daedra/.local/share/Steam/steam.sh: line 798: 3301 Segmentation fault "$STEAMROOT/$STEAMEXEPATH" "$@"
daedra@shodan:~$ crash_20240204105424_2.dmp[3304]: Finished uploading minidump (out-of-process): success = yes
crash_20240204105424_2.dmp[3304]: response: CrashID=bp-01749562-14c3-4521-b0e4-7f2112240204
crash_20240204105424_2.dmp[3304]: file ''/tmp/dumps/crash_20240204105424_2.dmp'', upload yes: ''CrashID=bp-01749562-14c3-4521-b0e4-7f2112240204''
I used Alien Bob's mirror_slackware_current.sh script to create an up to date 32bit iso, so my multilib packages are perfectly in sync with -current. I will start investigating and report back here if I find something.
Added my two cents to the nvidia thread. So strange that Arch isn't having the same problem. Normally if they encounter a strange bug, so do we. (Since slackware-current and arch are often on the same versions of things.)
Added my two cents to the nvidia thread. So strange that Arch isn't having the same problem. Normally if they encounter a strange bug, so do we. (Since slackware-current and arch are often on the same versions of things.)
Yes, I did check the Arch forums too but don't see any mention of it. Since it affects steam I would have expected a lot of people to have the problem.
Arch also seems to have the same version of libglvnd without any extra patches.
Arch does use different configure options when building 32bit glibc though (I think)
So I'm wondering if it's something 64-bit has that 32-bit doesn't, namely something added to Slackware that needs to be picked up for multilib. Here's a complete list of everything that was added since Jan. 5, the last time multilib was refreshed:
If it was a missing library then it just wouldn't work at all, even when run with gdb or strace.
The reason I think it's something to do with the way the nvidia libGLX_nvidia is compiled is because it works OK when forcing libGLX_mesa instead.
ldd /usr/lib/libGLX_nvidia.so.0 shows that no libraries are missing for me. Maybe we could try rebuilding some of the libraries listed there though, like libxcb, libXau, libXdmcp.
edit: it looks like they are all built as part of a bigger x11 build script, so can't just build them individually
I just recompiled glibc 2.39 multilib and added the configure options that are present in the Arch build script (except --enable-systemtap) but I still get the same segfault with glx.
In the past, though, whenever there's been an unexplained issue with a library and multilib, it's usually something missing from multilib. My logic was that 64-bit slackware works, so it's got something the multilib set doesn't have, since a whole lot was added to it. Aside from that and what's been tried here, I'm not sure. There's not much movement on the nvidia forum thread.
I know what you mean about waiting for multilib to catchup, I have noticed that before too in the past
This problem only started for me after installing updates yesterday, and those updates were:
Code:
-rw-r--r-- 1 root root 4036 Feb 3 21:19 SDL2-2.30.0-x86_64-1
-rw-r--r-- 1 root root 432161 Feb 3 21:20 calligra-3.2.1-x86_64-36
-rw-r--r-- 1 root root 16024 Feb 3 21:20 cantor-23.08.4-x86_64-2
-rw-r--r-- 1 root root 5573 Feb 3 21:20 fetchmail-6.4.38-x86_64-1
-rw-r--r-- 1 root root 1765 Feb 3 21:20 ipset-7.20-x86_64-1
-rw-r--r-- 1 root root 136778 Feb 3 21:21 kernel-firmware-20240201_09f0fb8-noarch-1
-rw-r--r-- 1 root root 31636 Feb 3 21:21 kernel-headers-6.6.15-x86-1
-rw-r--r-- 1 root root 10873 Feb 3 21:21 kfilemetadata-5.114.0-x86_64-3
-rw-r--r-- 1 root root 98197 Feb 3 21:21 kile-2.9.93-x86_64-30
-rw-r--r-- 1 root root 11288 Feb 3 21:21 kitinerary-23.08.4-x86_64-2
-rw-r--r-- 1 root root 79095 Feb 3 21:21 krita-5.2.2-x86_64-3
-rw-r--r-- 1 root root 10248 Feb 3 21:22 libindi-2.0.6-x86_64-1
-rw-r--r-- 1 root root 995 Feb 3 21:22 libusb-1.0.27-x86_64-1
-rw-r--r-- 1 root root 4397 Feb 3 21:22 mesa-24.0.0-x86_64-1
-rw-r--r-- 1 root root 81545 Feb 3 21:22 okular-23.08.4-x86_64-2
-rw-r--r-- 1 root root 42176 Feb 3 21:22 pipewire-1.0.3-x86_64-1
-rw-r--r-- 1 root root 11042 Feb 3 21:22 poppler-24.02.0-x86_64-1
Also multilib glibc 2.39 - but since I have been playing with different versions that isn't showing up as installed at the same time any more.
I was sure it was glibc 2.39 which caused the problem.. but I have now recompiled glibc 2.38 and I am still getting exactly the same segfault. So now i'm more confused
Edit: just had another thought about the kernel headers. Maybe since I have the 6.6.15 kernel headers installed now, my glibc build used them and so it's not the same as the old 2.38 that was built before. I'm not sure if they would make a difference to the resulting glibc but I guess trying with older kernel headers is something I could test tomorrow.
Edit: just had another thought about the kernel headers. Maybe since I have the 6.6.15 kernel headers installed now, my glibc build used them and so it's not the same as the old 2.38 that was built before. I'm not sure if they would make a difference to the resulting glibc but I guess trying with older kernel headers is something I could test tomorrow.
I don't think it's 6.6.15. I tried 6.6.14 with nividia drivers compiled for 6.6.14, and I was getting the same segfault. (My theory was it was the patch causing issues.) 6.6.14 was working fine yesterday before updating.
I wish I had an AMD card I could toss in and see what happens.
I don't think it's 6.6.15. I tried 6.6.14 with nividia drivers compiled for 6.6.14, and I was getting the same segfault. (My theory was it was the patch causing issues.) 6.6.14 was working fine yesterday before updating.
I wish I had an AMD card I could toss in and see what happens.
I am not so sure it's the nvidia patch either. As a test I recompiled the kernel with the patch that Bathory provided here. After compiling the kernel I was able to build both the nvidia-driver and nvidia-kernel without patching, but still got the error unless I ran steam and 32bit glxgears with strace.
I have now installed the linux kernel headers 6.6.8 and used them to rebuild glibc-2.38 and libglvnd but still getting the segfault.
Also other libraries listed by ldd for glxinfo and libGLX_nvidia.so were last modified before February. So that should mean I have all the versions back to how they were before it went wrong, but it's still not working.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
