/usr/lib64/GLoverride:/usr/lib/GLoverride is a Martinos Center specific thing. This is where I copy the original Mesa libGL.so.* files before they get overwritten by the ATI or Nvidia installers. Unfortunately the dang NVIDIA installer keeps finding them there and deleting them so I have to restore them from a special copy I made of the Mesa libs in a safe place.
Also, I use an older copy of the Mesa libs than what comes with the latest CentOS5 as those Mesa libs seem to cause apps to crash.
On Fri, 27 Feb 2009, Nick Schmansky wrote:
David,
Here at the MGH NMR Center we have a number of centos5 32b and 64b machines that run freesurfer, including tksurfer.
In your case, you are running it via an X-Windows server on a Windows machine, which introduces an additional complication, since the client and server drivers must both support GLX (in a way that, unfortunately, I don't fully understand, that is, exactly which modes and features must be communicated between the Windows native driver, the Windows X server, and the X client on the Linux server running freesurfer). The glxinfo that you provided me unfortunately did not reveal any clues, as the versioning all appeared to be the same.
You could try defining these on the Linux server:
setenv LD_LIBRARY_PATH "/usr/lib64/GLoverride:/usr/lib/GLoverride"
to force use of the Mesa GL libs, overriding any native graphics drivers installed (which I assume are fully up-to-date in their versions, ie, in the case of nvidia, nvidiainstaller --update has been run).
If anybody on the list has had experience running tksurfer remotely using Windows Reflection X connecting to a Fedora Core 5 or Centos 5 server, let us know.
Also, you could try using VNC instead of Reflection X. This is what we use for remote connectivity.
Nick
On Fri, 2009-02-27 at 09:25 -0800, David Mischel wrote:
Hello, everyone. I received a very nice note from Siddharth Srivastava in response to my initial post. Unfortunately, his suggestion (shared library load order) did not have any effect. On a closer look I see that the tksurfer script, which calls tksurfer.bin, already ensures that the correct FS TCL library path is put first in the share library load order.
Since the same script is executing the same code on different operating systems I am still thinking that some variant in the system libraries for rendering are part of the problem.
Can anyone using a CentOS 5 host for tksurfer confirm whether it is correctly displaying whole brain images? I would appreciate getting a positive case report.
Thanks,
< david
Message: 7 Date: Thu, 26 Feb 2009 13:48:34 -0800 From: David Mischel David.Mischel@ucsf.edu Subject: [Freesurfer] tksurfer display problems vary by OS version To: freesurfer@nmr.mgh.harvard.edu Message-ID: 49A70E32.1070409@ucsf.edu Content-Type: text/plain; charset="iso-8859-1"
Hello, everyone.
I just joined this list in order to post a problem our folks are having with tksurfer displaying brain images. What we are seeing is incorrect display of images depending on what OS tksurfer is run on. In one case, the image is never rendered because some kind of error loop is triggered. In all test cases the same data and Freesurfer version are being used (4.0.1) and the same display hardware and software are being used. The only difference is the host OS running tksurfer.
Here's what we are seeing:
Operating system Result
Fedora Core 4 (32 bit) Success
Fedora Core 5 (64 bit) Failure (run away X errors)
Cent OS 5 (64 bit) Failure (incorrect image)
... Message: 8 Date: Thu, 26 Feb 2009 13:58:36 -0800 From: Siddharth Srivastava siddys@gmail.com Subject: Re: [Freesurfer] tksurfer display problems vary by OS version To: freesurfer@nmr.mgh.harvard.edu Message-ID: d440b0e10902261358q12704d8dn7468867e98c99a6f@mail.gmail.com Content-Type: text/plain; charset="iso-8859-1" Hi david, I dont know if this will help, and i really do not know the reason why it should work, but if you append the tcltktixbli/lib, /usr/lib and /usr/lib64 on 64 bit version *in this order*, the tksurfer problems are solved. ...