The previous stock glibc-2.38 was built 2023-10-13 (Pat) or 2023-10-14 (Eric). It was built against the latest kernel headers at that time. It was kernel-headers-6.1.57 (2023-10-11). There shouldn't be much or any difference between the 6.6.8 and 6.6.15 headers, but in principle, there could be some difference between 6.1.57 and 6.6.15 headers. Maybe you could try to rebuild glibc-2.38 against the 6.1.57 headers?

1 members found this post helpful.

Ah ok, I will try with older headers later then
The reason I used 6.6.8 is because that's the kernel I currently have installed, and it was after updating to 6.6.15 that people needed an extra patch to build the nvidia module.

Or you could use Alien Bob's old multilib glibc-2.38. Google found a mirror not upgraded yet: https://www.slackjeff.com.br/multilib/current/. If you check the packages against the gpg signatures, it should be safe.

1 members found this post helpful.

Thanks, I had tried searching for old versions but google just kept sending me to Eric's site, and archive.org only had 2.37. Eric still has the signatures up on his site so I can use them to verify.

Finding those old packages made things much easier
I have just reinstalled Eric's original versions (verified the md5sums) and now 32bit glxinfo and steam are working fine again.

Just before, I did recompile glibc using kernel headers 5.15.145 from Slackware-15.0 since it was easy to install them but that glibc also caused a segfault.

So there seems to be something else different about those 2.38 packages. GCC hasn't been updated since August 2023 so shouldn't be that. Maybe binutils makes a difference? But Arch is also using binutils-2.42.

The working versions for me are:
glibc-profile-2.38_multilib-x86_64-3alien.txz
glibc-i18n-2.38_multilib-x86_64-3alien.txz
aaa_glibc-solibs-2.38_multilib-x86_64-3alien.txz
glibc-2.38_multilib-x86_64-3alien.txz

1 members found this post helpful.

I have just rebuilt binutils-2.41 but without the binutils-readelf-other-sym-info.patch.gz patch which seems to have been added for the 2.42 build.
I then rebuilt glibc-2.38 again using my binutils-2.41 and kernel-headers 5.15. This glibc 2.38 is also working with 32bit GLX.

So now I'm not sure if the problem is binutil-2.42, the binutils-readelf-other-sym-info.patch.gz patch, or does it just work because I built it while I already had Eric's original glibc-2.38 installed? So many possibilities

I guess the next thing to try is update everything except binutils and then recompile glibc-2.39 using binutils-2.41.

1 members found this post helpful.

https://slackware.uk/cumulative/ Does this help out any?

So if glibc 2.39 is the issue, could it be something with our build? I'm still stuck on arch having binutils 2.42 and glibc 2.39 and no problems reported... That would indicate an issue with us, correct? (And why Christesrun isn't having problems.)

1 members found this post helpful.

It doesn't look like glibc-2.39 is really the issue, since when I compiled my own 2.38 that also didn't work - so it looks more like the tools used to build glibc are causing the problem.
If Christesrun is using an old version of the nvidia driver it might not be using libglvnd and programs are just linked directly to the nvidia libGLX. The crash is happening when libglvnd tries to load the nvidia libGLX.

I have just updated my system again now apart from binutils (it looks like a lot of compat32 updates are there now too). After the update 32 bit glx is broken again. So now I will rebuild glibc-2.39 using binutils-2.41 and see what happens.

edit: glibc-2.39 built with binutils-2.41 + kernel-headers 6.6.15 works. So next is to try binutils-2.42 without the readelf patch.

2 members found this post helpful.

https://gitlab.archlinux.org/archlin...ls/-/tree/main Could be something to it. They don't use the readelf patch.

1 members found this post helpful.

I tried building binutils-2.42 with all but the readelf patch, and then glibc using kernel-headers 6.6.15 but that gave a bad glibc.
Since they only used the gold-warn-unsupported patch in arch I tried building binutils-2.42 with only that patch but that also resulted in a bad glibc.
I now got a good glibc-2.39 by using binutils-2.41 with all but the readelf patch.

So far I have:
I wonder if I now try rebuilding binutils 2.42 using my good glibc it will result in a binutils which can build another working glibc.

I have uploaded my working glibc-2.39 which was compiled with binutils-2.41 and headers 6.6.15 to http://135.125.183.217/glibc/ in case anyone wanted to test if it works for them. At your own risk of course

Hrm. I wonder why we need the readelf patch? (Is Pat lurking? Some insight would be interesting.)

The only reason I built 2.41 without the readelf patch is because it wouldn't apply to 2.41 but when I built 2.42 without it, that also didn't fix the glibc problem.

edit: just tried again building binutils-2.42 with all except readelf patch, and rebuilding glibc starting with a working glibc this time and the result is a broken glibc again. So it looks like binutils-2.42 is causing the problem somehow.

There was a binutils-readelf-other-sym-info.patch already in slackware-15.0 (binutils-2.37). It's from fedora:
I guess some builds run readelf and expect a certain output.

Would you do this test? Install a bad glibc-2.39 produced by binutils-2.42. And then copy only /lib/libdl-2.33.so from a good glibc-2.39 produced by binutils-2.41. Does the good libdl fix GLX?

I will do, I am just building another glibc-2.39 using binutils-2.42 with arch configure options which I expect to end up bad so I can use that for your test.

While looking at the Arch build script I saw the comment
So now I am also wondering if gcc needs to be rebuilt after building a new binutils, and use that to create the new glibc. Since gcc hasn't been rebuilt since the binutils upgrade on Slackware that might be why using binutils-2.41 is working for me since the current gcc was built with binutils-2.41.