Hi Darren,
we have made no mods to FSL, nor do we plan to. We just include it for one-stop-shopping.
Bruce
On Sun, 26 Feb 2006, Darren Weber wrote:
I have the dev version installed and running on Debian Sarge (I tried an upgrade from sarge to etch for a while, but it was unstable in too many important ways for me to continue using it for daily work). On sarge, the only problem was creating a symlink for libtiff.so.3:
# cd /usr/lib # ln -s libtiff.so libtiff.so.3
because the current version of libtiff is at libtiff.so.4, so this hack will link into the so.4 version - I hope this will work, it seems to be OK, but I haven't tried to save any tiff files yet.
I don't know enough about how the linking process is resolved, so I can't help wondering if the linking process during the builds can refer to the lib*.so versions, that are most often symlinks to the latest library versions.
Is anyone working on a .deb package for freesurfer? I hesitate to even start, for too many reasons. As freesurfer moves toward an open source project, it would be nice to see the download size decrease substantially. It should be possible to avoid inclusion of fsl, afni, mni, gsl, tcltk, etc. in the downloads for freesurfer. Most of these libraries or additional packages are open source projects in their own right (or very nearly open source).
In this regard, there are some considerations to think about. For example, I got the freesurfer dev download (what a download!). The first thing I did was # rm -f $FREESURFER_HOME/fsl because fsl was already installed in /usr/local/fsl, which was downloaded directly from Oxford (so they can keep track of all their downloads to substantiate their grants). I couldn't help wondering if the freesurfer developers might have obtained the fsl source code, to make some changes of their own. If so, I just wiped out those changes! Even if there were no changes to fsl in the freesurfer distro, I still have a fleeting question about whether to use the freesurfer fsl or the Oxford fsl. Are they the same thing, what version differences are there, which one should I use? That is, do I have to check the versions and then make a decision about which one to use. Do I have them both installed and use extra disk space for no reason? If I do the latter, how many copies of the dependent libraries are now installed on my system? The same problem appears, to some extent, in fsl also. The Oxford download includes tcltk, qt, etc. libraries. I would hope that these neuroimaging packages will be integrated into reasonable package management systems (apt, yum, etc.) that detect and install dependencies into centralized file system locations (/lib, /usr/lib, /usr/local/lib, etc.) rather than have all these extra libraries installed all over the place. I guess developers are taking the easy way out, or the safe option, by including the libraries in the downloads and providing a config file that locates them for their application. With larger and larger disks, who cares about disk space. The installations are then immune to linux distro upgrades. However, I wonder if fanatical system admins, with security on their minds, will ever exclude installation of fsl, freesurfer, etc. because they do not integrate with security update models (eg, library updates). I can tell you that recent US legislation about privacy of information in hospital computer systems is fanatical, security is on the minds of our system admins.
Best, Darren
wilms wrote:
Dear Nick,
I tried the newest centos4 build (20060223) but to no avail. I still cannot see bert's entire pial surface using the command
tksurfer bert rh pial
Do you have further suggestions? Do you know of someone using freesurfer under debian "etch"?
Marcus
Nick Schmansky wrote:
Marcus,
You may want to try the centos4 build of freesurfer. It is built against libstdc++.so.6, whereas the rh9 build builds against libstdc+ +.so.5.
I don't know whether this would account for the partial brain you are seeing, or why, but its worth a try.
Nick
On Wed, 2006-02-22 at 10:58 +0100, wilms wrote:
Dear all,
does someone out there run freesurfer (freesurfer-Linux-rh9-dev20060210-full.tar.gz) under debian etch? Installation runs smoothly, however, when I test the freesurfer installation with
medpc32:~$ tksurfer bert rh pial
only a tiny fraction of Bert's brain is displayed. The GUI otherwise seems to work as I can rotate etc this brain fraction.
I installed the same freesurfer version on a different computer running debian "sarge", which is the current stable distribution. - Here, I can see the whole brain!
As suggested elsewhere I thus compared the shared library dependencies using
medpc32:~$ ldd `which tkmedit`
Here is what I got:
######### "etch"-machine: #########
medpc32:~$ ldd `which tkmedit` linux-gate.so.1 => (0xffffe000) libtix8.1.8.3.so => /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtix8.1.8.3.so (0xb7fb0000) libtk8.4.so => /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtk8.4.so (0xb7ef0000) libtcl8.4.so => /local/opt/freesurfer_dev20060210/lib/tcltktixblt/lib/libtcl8.4.so (0xb7e57000) libglut.so.3 => /usr/lib/libglut.so.3 (0xb7e0d000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7e04000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7dec000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7dd6000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb7dce000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7d4f000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7ceb000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c20000) libgsl.so.0 => /local/opt/freesurfer_dev20060210/lib/gsl/lib/libgsl.so.0 (0xb7acc000) libgslcblas.so.0 => /local/opt/freesurfer_dev20060210/lib/gsl/lib/libgslcblas.so.0 (0xb7a9c000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7a7c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7a2a000) libz.so.1 => /usr/lib/libz.so.1 (0xb7a15000) libm.so.6 => /lib/tls/libm.so.6 (0xb79ef000) libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb79c1000) libc.so.6 => /lib/tls/libc.so.6 (0xb788a000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb7886000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7878000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb7827000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb774a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb773f000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb772d000) libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb7728000) /lib/ld-linux.so.2 (0xb7feb000)
######### "sarge" machine: #########
kogneuro-web:~$ ldd `which tkmedit` libtix8.1.8.3.so => /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtix8.1.8.3.so (0xb7fae000) libtk8.4.so => /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtk8.4.so (0xb7eee000) libtcl8.4.so => /local/data/tools/freesurfer/lib/tcltktixblt/lib/libtcl8.4.so (0xb7e55000) libglut.so.3 => /usr/lib/libglut.so.3 (0xb7e1b000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb7e12000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb7dfb000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0xb7de4000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb7ddc000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7d61000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb7cf2000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7c2b000) libgsl.so.0 => /local/data/tools/freesurfer/lib/gsl/lib/libgsl.so.0 (0xb7ad7000) libgslcblas.so.0 => /local/data/tools/freesurfer/lib/gsl/lib/libgslcblas.so.0 (0xb7aa6000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7a88000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7a38000) libz.so.1 => /usr/lib/libz.so.1 (0xb7a26000) libm.so.6 => /lib/tls/libm.so.6 (0xb7a04000) libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb79d7000) libc.so.6 => /lib/tls/libc.so.6 (0xb78a1000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb789e000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb7890000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0xb783f000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7785000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7779000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb776a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
The differences seem to be:
######### "etch" machine: ######### libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb774a000) libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0xb7728000) /lib/ld-linux.so.2 (0xb7feb000)
######### "sarge" machine: ######### libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7785000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
Does this mean that the c++ libraries on my etch-running machine are "too" new? Why is there no "=>" for /lib/ld-linux.so.2 on my etch-running machine?
I would greatly appreciate any comments or ideas what else I could do.
Many thanks in advance,
Marcus