View previous topic :: View next topic |
Author |
Message |
may1937 n00b
Joined: 29 May 2002 Posts: 15
|
Posted: Wed May 29, 2002 10:03 pm Post subject: nvidia and gcc 3.1 |
|
|
I spent last night installing gentoo with gcc 3.1 and binutils 2.12. I finally got it working by tweaking the bootstrap.sh script to stop after building glibc with a CFLAGS of "-march=i686 -O3 -pipe". Then I changed the CFLAGS to their full -march=pentium3 +optimizations glory and finished the bootstrap. I then emerged system and the rest. X wouldn't compile with older gcc 3.1's, but with r4 it works fine. I could never get glibc built with CFLAGS higher than -march=i686... all my binaries would just segfault lol. Perl builds fine, but you have to unmask r4.
Anyway on to my question -- there is an undefined symbol "__divdi3" in libGLcore.so.1 (nvidia drivers). I think gcc 3.1 changed where this symbol is located or something. I found it in libgcc.a and libgcc_s.so and even tried LD_PRELOADing libgcc_s.so (I also tried LD_PRELOADing libgcc.a, but you all should learn from my mistakes and never ever LD_PRELOAD a static lib because the linker has nfc and all binaries cease to work heheh) but didn't have any luck. Is it possible to get this working, or am I gonna have to try installing gcc 2.95.3 just to use my stupid binary drivers? |
|
Back to top |
|
|
lx Veteran
Joined: 28 May 2002 Posts: 1012 Location: Netherlands
|
Posted: Thu May 30, 2002 12:06 am Post subject: |
|
|
I'm running the latest nvidia-drivers and nvidia-glx, compiled with gcc 3.1 (march=athlon-tbird) and they work fine. Code: | objdump -T /usr/lib/opengl/nvidia/libGLcore.so.1.2960 | grep __divdi3 |
result:
Quote: | 00000000 D *UND* 00000000 __divdi3 |
so it requests the same function here. Got to find out who's supplying __divdi3. when using nm i find a refernce to it /usr/lib/liblcms.a but i'm not sure that's right, its part of the package media-libs/lcms-1.0.8 something to do with quick color management.
Hope it helps, lX
Ps: Does somebody now the correct way to find the library which provides a certain symbol? (using nm is just a wild guess). _________________ "Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
Back to top |
|
|
may1937 n00b
Joined: 29 May 2002 Posts: 15
|
Posted: Thu May 30, 2002 12:54 am Post subject: |
|
|
I get the same thing with objdump.. but doesn't the 00000000 stuff just mean that libGLcore references the __divdi3 funtion dynamically?? Anyway, I didnt mention before... 2D X works fine, but the glx module won't load due to the undefined symbol and thus i get no 3D stuff. Do you still have gcc 2.95 on your system? I don't and if you do maybe its still linking with some of the gcc 2.95 stuff? Just a guess.. |
|
Back to top |
|
|
Tuxisuau Apprentice
Joined: 04 May 2002 Posts: 213 Location: Catalunya (Europe)
|
Posted: Thu May 30, 2002 2:15 am Post subject: Built. |
|
|
I did install my system direcly with gcc-3.1 and my CFLAGS (-march=athlon -O3 -pipe).
I just built nvidia drivers with no problem...
err... there was problem
He tried to get gentoo-sources while i'm a happy xfs-sources user. I simply edited the ebuild and changed the dependency to xfs-sources. There's something wrong with xfs-sources, cause it doesn't set the kernel sources virtual/ package to point to it. |
|
Back to top |
|
|
may1937 n00b
Joined: 29 May 2002 Posts: 15
|
Posted: Thu May 30, 2002 2:39 am Post subject: |
|
|
Well I dunno about that kernel stuff... i use gentoo-sources, but this undefined reference is not during the nvidia install, its only when anything tries to link or use libGLcore. The nvidia-kernel and nvidia-glx portions installed without any problem. |
|
Back to top |
|
|
lx Veteran
Joined: 28 May 2002 Posts: 1012 Location: Netherlands
|
Posted: Thu May 30, 2002 12:18 pm Post subject: |
|
|
may1937 wrote: | I get the same thing with objdump.. but doesn't the 00000000 stuff just mean that libGLcore references the __divdi3 funtion dynamically?? |
Yep just wanted to show that my libGLcore also depends on __divdi3. glxgears runs fine
Quote: | root # ldd `which glxgears`
libGL.so.1 => /usr/lib/libGL.so.1 (0x40023000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4006a000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40078000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4013e000)
libm.so.6 => /lib/libm.so.6 (0x40154000)
libc.so.6 => /lib/libc.so.6 (0x40177000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x40299000)
libdl.so.2 => /lib/libdl.so.2 (0x40627000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4062c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
ls /usr/lib/libGLcore* -al
lrwxrwxrwx 1 root root 48 05-29 15:15 /usr/lib/libGLcore.so -> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.2960
lrwxrwxrwx 1 root root 48 05-29 15:15 /usr/lib/libGLcore.so.1 -> /usr/lib/opengl/nvidia/lib/libGLcore.so.1.0.2960
|
Are you sure the right libGLcore.so is used (the own from nvidia-glx-2960). _________________ "Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
Back to top |
|
|
jean-michel Tux's lil' helper
Joined: 30 May 2002 Posts: 142 Location: Somewhere East of the Atlantic
|
Posted: Thu May 30, 2002 2:40 pm Post subject: make mrproper |
|
|
Just on the off chance, have you tried backing up your /usr/src/linux/.config file and running a 'make mrproper' and rebuilding your kernel, then rebuilding the nvidia stuff? (NOTE: 'make mrproper' will blow away your kernel config, so back it up first and then restore it after running 'make mrproper' by copying the file back, then running 'make oldconfig')
I've often found that strange "undefined symbol" messages of this sort are fixed by doing that. I assume your X system was also built with GCC 3.1 (as was your kernel). _________________ The Struggle for the Future of Human Evolution Begins: Autonomy the SciFi Series! |
|
Back to top |
|
|
may1937 n00b
Joined: 29 May 2002 Posts: 15
|
Posted: Thu May 30, 2002 5:29 pm Post subject: |
|
|
Well the kernel module builds and insmods fine. The /proc info is all there like it should be. And yes, everything was compiled with gcc 3.1, I don't have any other version of gcc installed. The right libGLcore is being used and the links are all set properly..
lx - I see that your ldd of glxgears shows it linking to libgcc_s.so.1.... This is one of the libs that contains the __divdi3 function. My glxgears does not link to it, and now I am utterly confused. |
|
Back to top |
|
|
JefP@@ Apprentice
Joined: 09 May 2002 Posts: 179 Location: Belgium
|
Posted: Thu May 30, 2002 8:14 pm Post subject: |
|
|
may1937 wrote: | I get the same thing with objdump.. but doesn't the 00000000 stuff just mean that libGLcore references the __divdi3 funtion dynamically?? Anyway, I didnt mention before... 2D X works fine, but the glx module won't load due to the undefined symbol and thus i get no 3D stuff. Do you still have gcc 2.95 on your system? I don't and if you do maybe its still linking with some of the gcc 2.95 stuff? Just a guess.. |
Duno, this could be a stupid remark, but ... I've had somewhat the same prob. Sometimes my x crashes & I have to reboot. xfs then "fixes" the filesystem. As a result, the wrong libGL libraries are used ... (I have the same symptomes : NVdriver module is working & loaded, x works with nvidia binary driver, but when I run a glxinfo, I get some errors about xlib not finding glx or smth.). I fix this by executing "opengl-update nvidia" , which sets the correct libs etc...
I could be way off, so I apologize beforehand
Grtz |
|
Back to top |
|
|
lx Veteran
Joined: 28 May 2002 Posts: 1012 Location: Netherlands
|
Posted: Thu May 30, 2002 10:39 pm Post subject: |
|
|
may1937 wrote: | lx - I see that your ldd of glxgears shows it linking to libgcc_s.so.1.... This is one of the libs that contains the __divdi3 function. My glxgears does not link to it, and now I am utterly confused. |
Did you build X with gcc 3.1 (from your post I would think so), else there might be the problem. Well /usr/lib/....2.95.3/libgcc.a also contains __divdi3. Damn I need to get better aquanted with the library mechanism in linux.
Sorry, lX _________________ "Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
Back to top |
|
|
lasse n00b
Joined: 30 May 2002 Posts: 11 Location: Wellington, NZ
|
Posted: Fri May 31, 2002 12:55 pm Post subject: |
|
|
Right, I haven't proven this conclusively but I believe there are very good reasons to point the finger in the direction of binutils.
I've done 3.1-builds a few times now with various degrees of success. A few days ago I had a 3.1 system compiled with binutils 2.12.x. The nvidia driver was working fine but opengl would bomb out with the missing symbol (__divdi3).
I read this thread plus the one on doing a complete bootstrap using the i486 compiler flags (https://forums.gentoo.org/viewtopic.php?t=3685) and thought it might be worth having a shot at trying again with the older binutils.
The reasons for downgrading binutils came from this thread: http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html
A quick and quite possibly completely wrong summary of the redhat link is that pre-3.1 libgcc:s contained a bunch of symbols (incl. __divdi3) that got re-exported by the linker at compile time. This apparently introduces problematic dependencies/binary issues and and there was a mechanism added to the linker plumbing to allow for marking certain entry-points as hidden (i.e. so they don't get re-exported). The snag is that pre-3.1 gcc's didn't understand the HIDDEN attribute and re-exported the functions happily whereas 3.1 does enforce it and the symbols end up undefined. Apparently, the real issue is that the shared object (the nvidia opengl shared lib in this case, I assume) has not been built correctly. So, another case of "you used to get away with it but not so anymore", perhaps. Apologies all round if I'm barking up the wrong tree.
Anyway, what does binutils have to do with all this? The linking plumbing is provided by binutils and there is one posting in the thread mentioning that older binutils don't give a toss about the HIDDEN attribute.
Anyway, enough of the speculations. Building with gcc-3.1 and the older binutils (2.11.92.0.12.3-r2, what a whopper of a version number! Must be good!) works. At least for me...
The only other thing that is different from my previous build when nvidia opengl didn't work is that I've done the bootstrap using gcc-3.1 (thanks for the tip!). Whilst this could have something to with it I still think binutils is the more likely culprit.
To prove it I'd have to emerge the newer binutils and rebuild X. Just emerging the new binutils won't do since the critical stuff is happening at link time when shared libs and binaries are built. I wouldn't be happy doing a change like that without rebuilding the whole system and I've done that way too many times in the last few weeks so I'll leave it at this point.
So, now I have opengl but no combreloc. Just can't win, hey??
/Lasse |
|
Back to top |
|
|
may1937 n00b
Joined: 29 May 2002 Posts: 15
|
Posted: Fri May 31, 2002 4:45 pm Post subject: |
|
|
Ok so I just got up after a particularly rough night and was particularly pissed at opengl not working so for some reason I decided recompiling gcc would be a good idea but that didnt do anything so I thought I'd try LD_PRELOADing it again and damned if it didn't work. I put /lib/libgcc_s.so.1 in /etc/ld.so.preload, started up X, and yay it didn't say the glx module failed!! Well now I was real excited so I tried glxinfo and yay! Extensions glx wasn't missing anymore! And glxgears? YAY!! So I'm not sure if rebuilding gcc did anything (weird, eh?), but I know I tried LD_PRELOADing it before and it didn't work, so what the hell. Its not like its even a good solution, but hey at least its workin =] |
|
Back to top |
|
|
lx Veteran
Joined: 28 May 2002 Posts: 1012 Location: Netherlands
|
Posted: Fri May 31, 2002 5:10 pm Post subject: |
|
|
lasse wrote: | Right, I haven't proven this conclusively but I believe there are very good reasons to point the finger in the direction of binutils. |
I'm using 2.11.92.0.12.3-r2, and no problems with nvidia, maybe your on to something _________________ "Remember there's a big difference between kneeling down and bending over.", Frank Zappa |
|
Back to top |
|
|
Niek Apprentice
Joined: 14 May 2002 Posts: 236 Location: Houten, The Netherlands
|
Posted: Fri May 31, 2002 5:20 pm Post subject: |
|
|
Lasse, I've a idea. Perhaps it will works, perhaps don't:
* Install Gentoo with GCC 3.1 and binutils 2.12.*
* Emerge XFree, KDE, etc.
* Emerge binutils 2.11.*
* Build the nVidia drivers
* Emerge binutils 2.12.*
* Emerge other programs
Is that possible? In this case, you build the drivers with binutils 2.11, but the system is build and optimised with binutils 2.12 and the combreloc tweak. |
|
Back to top |
|
|
lasse n00b
Joined: 30 May 2002 Posts: 11 Location: Wellington, NZ
|
Posted: Fri May 31, 2002 10:54 pm Post subject: |
|
|
No, I don't think that would work. The nvidia drivers come as binaries so they already passed the crucial linking step. It's during the link step of an app or lib that the linker adds in the library dependencies. In the nvidia case I'm guessing they haven't explicitly added libgcc to the link-line when building the opengl lib so that dependency has to be satisfied by the "client" app, i.e. the application that links against the nvidia opengl lib.
So when building a client app under binutils 2.11 the linker sees that it needs to re-export libgcc in order for __divdi3 to be defined whereas under binutils 2.12 that re-export is explicitly forbidden and the symbol ends up undefined.
I'm guessing here but it could be that explicitly adding -lgcc to the link-line in the appropriate makefile for the client app would work.
Sadly that approach would be painful even if it did work since you'd have to change the link line of every opengl app.
The better solution IMHO would be to simply to expand on the LD_PRELOAD approach and add this to /etc/ld.so.preload:
/usr/lib/libgcc_s.so
This way it becomes the system default and you don't have to muck around with an environment variable. However, there may well be other reasons (security etc) why this isn't a good plan but it would enable using 2.12 and nvidia opengl until nvidia releases fixed drivers.
/Lasse |
|
Back to top |
|
|
may1937 n00b
Joined: 29 May 2002 Posts: 15
|
Posted: Fri May 31, 2002 11:09 pm Post subject: |
|
|
Although the drivers themselves work with the LD_PRELOAD stuff there are still some things that don't work. sdl-ttf would not build because of the undefined symbol even with LD_PRELOAD set, so I'm asssuming this is probably the case compiling most opengl apps. Maybe if we ask real nice nvidia will recompile with gcc 3.1 and newer binutils? |
|
Back to top |
|
|
jano n00b
Joined: 02 Jun 2002 Posts: 4
|
Posted: Sun Jun 02, 2002 12:54 am Post subject: |
|
|
Okay, I don't understand what any of all the above means. However, I, too, have this glx glcore problem with X on a gcc3.1 system (as of yesterday). To summarize what those above wrote,
echo "/lib/libgcc_s.so" > /etc/ld.so.preload && env-update
X loads without errors. The part to beware of: that preload file (whatever it is, i have no idea) is occasionaly cleaned/wiped/cleared, and so requires the user to repeat the above steps.
I have absolutley no idea what any of that does. But it works. Would someone mind explaining what the problem is (in lay-man's terms) and what the above actually does?
jano |
|
Back to top |
|
|
may1937 n00b
Joined: 29 May 2002 Posts: 15
|
Posted: Sun Jun 02, 2002 1:30 am Post subject: |
|
|
/etc/ld.so.preload is a system wide way of using LD_PRELOAD. LD_PRELOAD is a linker feature that is set through an environment variable (i.e. 'export LD_PRELOAD=/usr/lib/somelib.so') and it, from what I understand, loads the specified library even if a binary is not specifically linked to it and the functions in the preloaded library override any functions of the same name. So since libGLcore is missing the __divdi3 function and it is contained in libgcc_s, we can use LD_PRELOAD to make the __divdi3 function available to libGLcore.
Did that make any sense? |
|
Back to top |
|
|
lasse n00b
Joined: 30 May 2002 Posts: 11 Location: Wellington, NZ
|
Posted: Sun Jun 02, 2002 5:40 am Post subject: |
|
|
may1937 wrote: | Although the drivers themselves work with the LD_PRELOAD stuff there are still some things that don't work. sdl-ttf would not build because of the undefined symbol even with LD_PRELOAD set, so I'm asssuming this is probably the case compiling most opengl apps. Maybe if we ask real nice nvidia will recompile with gcc 3.1 and newer binutils? |
This is exactly the same problem again only now it happens at link-time rather than runtime. Fortunately, there are two quite easy ways around this:
1) Make sure the xfree opengl implementation is active when doing [opengl] builds. I.e. run "opengl-update xfree" and then emerge the package. The xfree library doesn't have the problem of unresolved symbols so the linking will work fine. This leaves us with the runtime issue for nvidia opengl and we already know how to deal with that.
2) Instead of doing
emerge anOpenGLPkg
do
LDFLAGS=-libgcc_so emerge anOpenGLPkg
This tells the linker to always add -libgcc to the link line and thus the symbols exist at linktime as well.
I've successfully built various opengl packages with these approaches.
HTH,
/Lasse |
|
Back to top |
|
|
lasse n00b
Joined: 30 May 2002 Posts: 11 Location: Wellington, NZ
|
Posted: Sun Jun 02, 2002 9:19 am Post subject: |
|
|
Oops, should be
LDFLAGS=-lgcc_s emerge anOpenGLPkg
/Lasse |
|
Back to top |
|
|
jano n00b
Joined: 02 Jun 2002 Posts: 4
|
Posted: Thu Jun 06, 2002 3:43 am Post subject: |
|
|
interestingly enough, i found out i needed the /lib/libgcc_s.so in there to work with java 1.4 from sun.
Heh |
|
Back to top |
|
|
rac Bodhisattva
Joined: 30 May 2002 Posts: 6553 Location: Japanifornia
|
Posted: Sun Aug 18, 2002 11:25 pm Post subject: |
|
|
GCC3 to Other Things Gentoo, to join Possible *real* __divdi3 fix. _________________ For every higher wall, there is a taller ladder |
|
Back to top |
|
|
|