I'm using Linux From Scratch mostly-3.3 (I like 3.0's boots scripts better, and I compiled everything with gcc 3.2 with the new -march=athlon-xp switch, so that's why it isn't totally LFS 3.3). In past iterations of Linux and the nVidia card drivers (even in other LFS installations, but in Mandrake also), all I've had to do is install X, install the nVidia kernel and GLX, change X's config file to use the right driver, load glx and not load GLcore and dri, and start up X.

This time, unfortunately, while the above method does get X going, GLX won't load. glxinfo after X is running gives a bunch of "extension GLX missing on display :0.0" errors, and the relevant parts (why glx won't load) of the log file are reproduced here:

The problem is the first set of errors, where dlopen() is complaining that __divdi3 is undefined somewhere.

There are no conflicting Mesa libGL* files anywhere; libGLcore.so.1 is a symlink to libGLcore.so.1.0.2960. libGL.so is also symlinked to the correct nVidia libGL, and ldding this libGL shows it dynamically loading libGLcore (the correct one, installed by the GLX tarball). ldding libGLcore.so.1.0.2960 says it's statically linked.

The NVdriver module does load.

My question is, has anyone seen anything like this before, and what can I do about it? Does it sound like a binutils or glibc error (possible, if it's happening as part of the dlopen() process), or is it a problem inside libGLcore? Of course, we don't get the source for that one, so unfortunately, I can't just check that...

If no one has seen it before, I can always email nVidia's linux-bugs address, but I figured it might have happened to someone.

Again, everything compiled with gcc 3.2 for the Athlon XP, glibc 2.2.5 with the linuxthreads addon, binutils 2.13, kernel 2.4.19 (with the -preempt patch, but I don't think that would do this), X 4.2, driver version 1.0-2960.

Differences I can think of between this installation and previous ones:

New gcc/g++ (it used to be 2.95.3)
New glibc (used to be 2.2.4-linuxthreads)
Just about everything compiled with -O3 -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse

glibc was compiled from tarballs, but with optimization. So I'll try that again, backing down to whatever the default is (-O3 I think? Maybe just -O2... whatever it is, there's no specific CPU optimization, but oh well), and we'll see if that helps.

The default was -O2, but that didn't help. Searching through the sources only finds __divdi3 in one place, in a Versions file that seems to indicate the symbol is part of the gcc library... hmmm, interesting.

Recompiling gcc (again) as we speak, and glibc will be compiled again after that.

__divdi3 is exported properly (at least, nm can find it) by /lib/glibc-2.2.5.so, which is symlinked to /lib/libc.so.6, so might it be that libGLcore is statically linked, and therefore not seeing libc?

... on second thought, if it was statically linked, it'd have __divdi3 in itself. Not to mention, no one else would be able to run it if that was the problem. Hmm..... I'm hoping that recompiling X against the proper libc will fix things. <crosses fingers>

Which makes it sound like it's libGLcore.so.1 that's causing the problem after all....

I wonder if this has anything to do with the new gcc 3 ABI (basically, the binary format, if I understand it correctly). If libGLcore can't load because the loader doesn't understand part of it, or ... something.

I think it's time to e-mail linux-bugs, unless anyone comes up with anything...