/usr/lib/opengl/nvidia/libGL.so doesn't exist. /usr/lib/opengl/nvidia/lib/libGL.so does exist. I didn't have any problems before emerging opengl-update (and going from XFree86 ~v4.2.0-r6 to XFree86 v4.2.0-r12). Unemerging and remerging nvidia-glx as well as running opengl-update nvidia seems to have no effect. ld.so.cache contains the proper location. Any ideas to the cause? Anyways, a work around is to just generate a symbolic link pointing to the correct location. Doing so at least resolves the issue of compiling xine-lib, and I'd assume as well for other GL apps.
I'll take a look at this as I happen to use all of the things listed in here...
try running opengl-update xfree emerge xine-lib xine-ui opengl-update nvidia startx xine -V opengl and let me know how it goes :)
gcc: /usr/lib/opengl/nvidia/libGL.so: No such file or directory make[4]: *** [xineplug_vo_out_opengl.la] Error 1 That's after running: opengl-update xfree emerge xine-lib xine-ui Other ideas?
have you seen anyone else with this issue? Have you checked that your /etc/ld.so.conf isn't funky in some way? I have so far been unable to reproduce this bug no matter what I try.
is this still an issue?
I've seen no one else with this problem. The /etc/ld.so.conf is quite sane. A symbolic link from the improper path to the real path allows compilation and the programs to work fine, but that doesn't solve what's causing the root problem, so I'd say it's not resolved.
i got the same problem here... can't compile any apps that link to libGL ...(not even kdelibs)
doing opengl-update xfree && emerge <package> ; opengl-update nvidia works most of the time..
Thomas, have you tried to ln -s from the real location to the location which the ebuild is trying to emerge from? It might help. I know the opengl-update tool doesn't work for me, so we probably don't have the exact same problem. Seems strange, though.
what versions of gcc and glibc (including gentoo revisions) are youts using?
I was using gcc 2.95.x and glibc 2.2.4, at the time. I had to rebuild my gentoo system from scratch because of a dead HD. The problems haven't shown up since, so I'd assume it was just some issue of the upgrading process I did over time.
2.95.3-r7 2.2.5-r5 at the moment... i'll try to rebuild the drivers with --emptytree.. and hope it works ;)
I think this was a bug introduced by some upgrade process, which therefore only exists on system upgraded at a particular window of time and is therefore virtually untraceable.
