LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   32-bit GLX (nvidia) not working after update, unless running with strace (https://www.linuxquestions.org/questions/slackware-14/32-bit-glx-nvidia-not-working-after-update-unless-running-with-strace-4175733503/)

Petri Kaukasoina 02-05-2024 05:53 AM

Quote:

Originally Posted by af7567 (Post 6481375)
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.

Quote:

Originally Posted by af7567 (Post 6481470)
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.

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?

af7567 02-05-2024 06:04 AM

Quote:

Originally Posted by Petri Kaukasoina (Post 6481477)
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?

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.

Petri Kaukasoina 02-05-2024 06:19 AM

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.

af7567 02-05-2024 06:29 AM

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.

af7567 02-05-2024 06:40 AM

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

af7567 02-05-2024 07:10 AM

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.

garpu 02-05-2024 07:25 AM

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.)

af7567 02-05-2024 07:31 AM

Quote:

Originally Posted by garpu (Post 6481505)
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.)

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.

garpu 02-05-2024 07:51 AM

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

af7567 02-05-2024 09:35 AM

Quote:

Originally Posted by garpu (Post 6481514)
https://gitlab.archlinux.org/archlin...ls/-/tree/main Could be something to it. They don't use the readelf patch.

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:
Code:

original glibc-2.38 + binutils 2.41 some patches + kernel 5.15 -> good glibc-2.38
good glibc-2.38 + binutils 2.42 most patches + kernel 6.6.15 -> bad glibc-2.39
bad libc-2.39 + binutils 2.42 only gold patch + kernel 6.6.15 -> bad glibc-2.39
bad libc-2.39 + binutils 2.41 most patches + kernel 6.6.15 -> good glibc-2.39

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 :)

garpu 02-05-2024 09:38 AM

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

af7567 02-05-2024 09:40 AM

Quote:

Originally Posted by garpu (Post 6481540)
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.

Petri Kaukasoina 02-05-2024 10:27 AM

Quote:

Originally Posted by af7567 (Post 6481541)
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.

There was a binutils-readelf-other-sym-info.patch already in slackware-15.0 (binutils-2.37). It's from fedora:
Code:

# Purpose:  Changes readelf so that when it displays extra information about
#          a symbol, this information is placed at the end of the line.
# Lifetime: Permanent.
# FIXME:    The proper fix would be to update the scripts that are expecting
#          a fixed output from readelf.  But it seems that some of them are
#          no longer being maintained.

I guess some builds run readelf and expect a certain output.

Petri Kaukasoina 02-05-2024 10:34 AM

Quote:

Originally Posted by af7567 (Post 6481541)
So it looks like binutils-2.42 is causing the problem somehow.

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?

af7567 02-05-2024 10:48 AM

Quote:

Originally Posted by Petri Kaukasoina (Post 6481549)
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
Quote:

# toolchain build order: linux-api-headers->glibc->binutils->gcc->glibc->binutils->gcc
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.


All times are GMT -5. The time now is 01:47 AM.