Bug 29221 – opengl-update: hazardous ebuild

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description harakiri 2003-09-20 14:47:29 UTC]

I've been struggling with a very unstable system for a while now. My system
would freeze randomly causing loss of files and a lot of frustration. In
addition, every program using qt would display messages such as "extension GLX
not supported on display 0:0".

I use the nvidia video driver and re-emerged both nvidia-driver, nvidia-glx
several times and used opengl-update nvidia several times without any change.

I finally found out that nvidia-glx MUST NOT BE EMERGED WHILE RUNNING X! In my
oppinion the ebuild should warn about this with several beeps and colorful text
before emerging.

[Comment 1 Martin Schlemmer (RETIRED) 2003-09-23 07:39:28 UTC]

Cannot say I ever had an issue.  Yes, changing from xfree to nvidia opengl or
such do provide some nice crashes trying to run 3d stuff, but I never had
any issues just merging a new version of nvidia-glx.

I assume the issue is then more to "have opengl-update display a warning
if changing opengl implementation if running X already" ?  Also, you never
thought to restart X ?

[Comment 2 harakiri 2003-09-23 08:11:48 UTC]

Ok, I admit the error could have been to run opengl-update while running X. Yes, I did restart X. Several times. I did reboot several times. I lived with the problem for weeks. The errors only disappeared after emerging nvidia-glx and running opengl-update without X running. But yes, it could possibly be the opengl-command and not the actual nvidia-glx install that caused the problems...

[Comment 3 Max Moura Wolosker 2003-10-08 21:20:09 UTC]

As far I could see, the mess is related to env-update. If I run opengl-update
nvidia and start X, everything is fine. If I call env-update just after it,
I receive the following error when starting X:

dlopen: /usr/lib/libGLcore.so.1: undefined symbol: glDepthBoundsNV

and the module glx isn't loaded.

The strange thing is that opengl-update calls env-update, just before setting
the simbolic links to the OpenGL implementation. If you move the command
to the final of the script, the bug appears. Another detail: if you call
the scripts in the following order:

1- opengl-update nvidia
2- env-update
3- opengl-update nvidia

everything works fine. This is strange once the symbolic links env-update
inside  opengl-update on the third step finds are the same that env-update
on the second step finds.

[Comment 4 harakiri 2003-10-08 22:23:53 UTC]

I can verify this behaviour on my machine. (Nice hunt Max, thanks)

[Comment 5 Max Moura Wolosker 2003-10-12 18:06:22 UTC]

I believe this bug is the same described in #29434

I solved the problem running the NVIDIA-Linux-x86-1.0-4496-pkg0.run script
manually. I think the program removed the old libraries versions automatically
and, after that, opengl-update nvidia worked out as expected.

[Comment 6 Martin Schlemmer (RETIRED) 2003-10-13 14:04:35 UTC]

What old libraries ?

[Comment 7 Max Moura Wolosker 2003-10-13 21:42:39 UTC]

As I said in my previous message, this bug is duplicated in #29434 (marked
as fixed). When updating the nvidia-glx ebuild from version 1.0.4363 to 1.0.4496,
some files weren't removed, causing all the mess.

[Comment 8 SpanKY 2003-10-13 21:45:16 UTC]

*** This bug has been marked as a duplicate of 29434 ***

[Comment 9 SpanKY 2003-10-13 21:46:27 UTC]

about the only thing to be done is to perhaps add checks to either the nvidia
ebuilds or the opengl-update script to make sure there arent multiple copies
of the libraries hanging around

[Comment 10 Martin Schlemmer (RETIRED) 2003-10-14 14:17:35 UTC]

Mike, IMHO it should be an portage issue if anything - the old libs should
really be unmerged with the stale version.

[Comment 11 SpanKY 2003-10-14 14:32:19 UTC]

who is to say it is portage's fault ?
if some bug in a script caused the mtimes or something to be updated on the
libraries then portage would have left them there ...