Steve Morris wrote:
> Colin Guthrie wrote:
>> I wasn't aware that ldconfig was run at boot. I can only assume you
>> think it is as you mentioned cold booting.... I can't be bothered
>> looking to verify this fully but certainly a grep -r ldconfig
>> /etc/rc.* returned nothing.

> Yes, I assumed that given its functionality that it was run at boot
> time. Given its functionality, if it is not run at boot time then
> somebody has stuffed up, because this level of caching should be run at
> boot time, unless there is something else run that does the same thing.


No one's "stuffed up". There is no reason to run ldconfig unless
something has changed - e.g. something is installed or removed or
changed. Packages that need to will run it in their %post and %postun
scripts. Doing it at boot would only slow things down. I'm glad it was
just your assumption otherwise I'd have said we should remove it from
the boot process!!


>> If you start hacking about with things then it's much harder to give
>> support. If you start hacking it's assumed you can poke about and fix
>> things yourself.
>
> I added the module paths into xorg.conf (reflecting what used to have to
> be supplied) so that xorg would pick up the nvidia driver and gl driver
> directly, rather than go through alternatives processing which cooker
> does by default, when I was resolving the cooker performance issues on
> my system with Stefane. Doing this significantly improved performance,
> particularly with kicker menu caching (I don't have any figures to back
> this up, it is general perception).

This change should point towards the solution e.g. help pinpoint what
the problem is. I doubt it should be a permanent fix for your problem.
Either it highlights a problem on your system or it highlights a problem
in the packaging. More feedback is needed here.


>> And remember that the x11 module is only part of the whole GL
>> solution. The shared library (and sometimes a kernel module) make up
>> the other part(s).
> This might be true but the
> /usr/lib/xorg/modules/extensions/nvidia-current/libglx.so is a link to
> /usr/lib/xorg/modules/extensions/nvidia-current/libglx.so.173.08 which I
> assume is the module with the unknown symbol and hence can't be loaded.

To assume makes an ASS of U and ME ;) It's probably not that library
that has the missing symbol but the library it's loading. e.g. it's
probably trying to load libGL.so.1 or something. It expects to load the
nv provided version of this library but it's actually loading the nvidia
one.... this could be due to outdated library paths in the ld.so.conf.d
folder (or more accurately, the paths are probably fine after having
been set corretly by update_alternatives gl_conf but an outdated cache
due to not running ldconfig is causing the wrong library to be loaded...).

Running:
ldd /usr/lib/xorg/modules/extensions/nvidia-current//libglx.so may give
you info but only if it doesn't dlopen it and is linked against it.

This could also highlight if you have a partially updated system which
different versions of the nvidia library verses the x driver part. If
that's the case you should ask Anssi to put in some stricture requires
but really partial updates are not recommended anyway, so this is
probably overkill. You could argue the same is true of hundreds of
packages in the distro...

Col

--

+--------------------------+
|    Colin Guthrie     |
+--------------------------+
| cguthrie(at)mandriva.org |
| http://colin.guthr.ie/ |
+--------------------------+