Colin Guthrie wrote:
> 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!!
I apologise. The reason I said something was stuffed up, was I was
approaching this from the traditional caching perspective. Via
traditional caching the ldconfig process would only last for the life of
the current session, hence if that caching was necessary (presumably it
was otherwise there would be no need for ldconfig) it would need to be
redone each boot unless something else was providing that functionality.
>
>
>>> 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.
I have now run ldconfig (I have never had to run this in the past for
dependent processes to pick up the update-alternatives changes, so I
don't understand why I need to now), and I have commented out the
modulepath statements so that the load process will go through the
alternatives links, and will see what the impact is.
>
>
>>> 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...).
I certainly hope this is not the situation as that makes a mockery of
the error message. Using your example of libGL.so.1, if xorg is smart
enough to determine that it is this module that has the undefined
symbol, then it is smart enough to specify the error on that module not
the original link. Even better would be for it to list the chain so that
a determination could be made as to how it got there.
>
> 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...
I have supplied Anssi with both ll and ldd output of the link in
question. I don't do partial updates (assuming I understand what you
mean by this), but I do undertake segmented updates if necessary (what I
mean by this is that I will issue urpmi --auto-update and download and
apply all updates possible in the timeframe available, terminate the
process at the end of a block, and continue by issuing urpmi
--auto-update the next night, and so on until all updates are applied).
If this is an issue (even though it shouldn't be, all things considered)
then it highlights a potential issue in the distribution that has not
been considered.

regards,
Steve
>
> Col
>