nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   libGLcore dlopen() error (http://www.nvnews.net/vbulletin/showthread.php?t=1631)

bwkaz 09-07-02 07:36 PM

libGLcore dlopen() error
 
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:

Code:

(II) Loading font Speedo
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
dlopen: /usr/lib/libGLcore.so.1: undefined symbol: __divdi3
(EE) Failed to load /usr/X11R6/lib/modules/extensions/libglx.so
(II) UnloadModule: "glx"
(EE) Failed to load module "glx" (loader failed, 1)

And then, a little later, this:

Code:

(EE) NVIDIA(0): Failed to load glX
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

Thanks in advance for any ideas.

utiel 09-07-02 07:56 PM

Perhaps is a libc problem ( glibc )
 
I always have problems compiling glibc ( from CVS, from tarballs without optimizations is OK)

/lib# grep "__divdi3" *
Coincidencia en el fichero binario ld-2.2.90.so
Coincidencia en el fichero binario libc-2.2.90.so


I think this function is in any library, ld, or libc.

Good luck

bwkaz 09-08-02 07:25 AM

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.

Building it now...

bwkaz 09-08-02 08:21 AM

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.

bwkaz 09-08-02 11:55 AM

Hmmm, no change.

Off to recheck the way X's module handling was configured...

If anyone has any other ideas, I'd love to stop responding to myself ;)

__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>

bwkaz 09-09-02 06:49 AM

:(

Recompiling X didn't help either.

I've also noticed another (sort of the same, but not entirely) error, this one when running glxgears:

Quote:

glxgears: relocation error: /usr/lib/libGLcore.so.1: undefined symbol: __divdi3
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...


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

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.