nvidia and gcc 3.1

may1937 · n00b Joined: 29 May 2002 Posts: 15

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?

lx · 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.

may1937 · n00b Joined: 29 May 2002 Posts: 15

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

Tuxisuau · 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.

may1937 · n00b Joined: 29 May 2002 Posts: 15

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.

lx · Posted: Thu May 30, 2002 12:18 pm Post subject:

jean-michel · 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!

may1937 · n00b Joined: 29 May 2002 Posts: 15

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.

JefP@@ · Posted: Thu May 30, 2002 8:14 pm Post subject:

lx · Posted: Thu May 30, 2002 10:39 pm Post subject:

lasse · 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

may1937 · n00b Joined: 29 May 2002 Posts: 15

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 =]

lx · Posted: Fri May 31, 2002 5:10 pm Post subject:

Niek · 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.

lasse · 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

may1937 · n00b Joined: 29 May 2002 Posts: 15

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?

jano · n00b Joined: 02 Jun 2002 Posts: 4

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

may1937 · n00b Joined: 29 May 2002 Posts: 15

/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?

lasse · Posted: Sun Jun 02, 2002 5:40 am Post subject:

lasse · Posted: Sun Jun 02, 2002 9:19 am Post subject:

Oops, should be

LDFLAGS=-lgcc_s emerge anOpenGLPkg

/Lasse

jano · n00b Joined: 02 Jun 2002 Posts: 4

interestingly enough, i found out i needed the /lib/libgcc_s.so in there to work with java 1.4 from sun.

Heh

rac · 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