[elrepo] Nvidia Driver Performance: El Repo vs. NVidia's .run file

[Phil Perry]

On 26/04/16 19:08, EBradley at williams-int.com wrote:
> Hi Manuel, Phil, and Steve,
>
> Thank you all for the replies! And let me also apologize for my email
> client not following the thread structure in the list. I'll reply to
> everyone in this message so as not to disrupt the flow any more than
> necessary.
>
> Manuel:  I do now see why you requested the Xorg.0.logs and it appears
> that I took the long way around. I just wasn't sure if the libGL
> discussion was going to take us in another direction rendering your
> request moot, so I figured I'd post that info first.
>
> Phil:  Interesting, thanks for the info. Per your request, the ldd
> command shows that the el repo drivers are functioning as intended for
> glxgears and the system in general:
>
> [224 root at system]ldd /usr/bin/glxgears | grep libGL
>          libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x0000003953800000)
>          libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x0000003951600000)
>

As you note, all working correctly there.

> I did try the above on a few other applications (firefox, glchess,
> baobab) but either they weren't dynamic executables or didn't contain
> any links to libGL.so.1. I also wasn't able to get a clear result from
> the above in regards to Ansys Mechanical as it isn't clear exactly how
> it's launched when the user double-clicks on a results cell. I tried a
> few binaries within the installation directory, but either they too
> weren't dynamic executables or there's some other vendor-specific voodoo
> at work as Ansys likes to launch their Windows .exe files on Linux via
> mono. At any rate, I'm glad to see I was on the right track and not
> really surprised to find that it's the fault of the application.
> Unfortunately, I'm in the same boat as Steve in that it probably won't
> do much good for me to ask the developers of the app to fix the linking
> issue. I'll probably have to decide if it's easier for me to create a
> script that fixes the link after each kernel upgrade or go back to the
> nvidia.com drivers and explore installing them with the --dkms option so
> DKMS will recreate the kernel modules for the newly-installed kernel.
> Since neither of those options are under the scope of this list, I'll
> consider this issue resolved as far as el repo is concerned.
>

The package that installs the libGL library is mesa-libGL. So you'd only 
need to reapply your fix in the event of this package being updated 
(nothing to do with the kernel). It should be pretty obvious as your 
users will no doubt report their application is broken again! Looking at 
the changelog on my RHEL5 system (sorry, I don't have a RHEL6 install 
with Xorg to hand), it's not a package that gets updated that frequently.

Thus I would apply your workaround of manually creating the required 
symlink and make a note you'll need to reply it after any updates to 
mesa-libGL (most likely at any major point releases).

If the issue affects a lot of machines then look to a way to script / 
automate that process.

> Steve:  Thanks for the post re: Puppet. I'll take a look at that as a
> possible option going forward.
>
> Thanks again for the support on this issue and for the el repo project
> in general!
>
>
> Evan
>