Difference between revisions of "Documentation/4.0/ReleaseNotes"
(Prepend documentation/versioncheck template. See http://na-mic.org/Mantis/view.php?id=2887) |
|||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | <noinclude>{{documentation/versioncheck}}</noinclude> | ||
| + | |||
| + | |||
__TOC__ | __TOC__ | ||
| − | + | ||
| − | |||
| − | |||
==All Platforms== | ==All Platforms== | ||
| Line 19: | Line 20: | ||
==Linux== | ==Linux== | ||
| + | |||
| + | Slicer4 will not start if you have Slicer_HOME environment variable initialized to point to a directory different from your Slicer4 installation. | ||
=== CentOS 5.7 (provided by Matt House) === | === CentOS 5.7 (provided by Matt House) === | ||
| Line 27: | Line 30: | ||
As a workaround, I’ve created symlinks to the libraries with Slicer’s expected names (no ‘e’). This allowed me to run Slicer 4, though I still get a warning message stating (in abbreviated form) ‘SlicerQT-real: /lib64/libcrypto.so.0.9.8: no version information available (required by ./lib/Slicer-4.0/libarchive.so.8)’ | As a workaround, I’ve created symlinks to the libraries with Slicer’s expected names (no ‘e’). This allowed me to run Slicer 4, though I still get a warning message stating (in abbreviated form) ‘SlicerQT-real: /lib64/libcrypto.so.0.9.8: no version information available (required by ./lib/Slicer-4.0/libarchive.so.8)’ | ||
| − | + | === Fedora 13 (SPL systems) === | |
| + | |||
| + | Creating symlinks on /usr requires root privileges. In the cases when this is not achievable, symlinks can be created in any directory, and LD_LIBRARY_PATH environment variable should be initialized accordingly. Here are the specific steps how this can be done: | ||
<pre> | <pre> | ||
| − | > cd | + | > cd ~ |
> mkdir local | > mkdir local | ||
| + | > cd local | ||
> ln -s /usr/lib64/libcrypto.so libcrypto.so.0.9.8 | > ln -s /usr/lib64/libcrypto.so libcrypto.so.0.9.8 | ||
> ln -s /usr/lib64/libssl.so.1.0.0d libssl.so.0.9.8 | > ln -s /usr/lib64/libssl.so.1.0.0d libssl.so.0.9.8 | ||
| − | > setenv LD_LIBRARY_PATH | + | > setenv LD_LIBRARY_PATH ${HOME}/local |
</pre> | </pre> | ||
(these exact commands should work for the SPL systems) | (these exact commands should work for the SPL systems) | ||
Latest revision as of 07:30, 14 June 2013
Home < Documentation < 4.0 < ReleaseNotes
|
For the latest Slicer documentation, visit the read-the-docs. |
Contents
All Platforms
Naming conventions of the download files:
- i386 means 32 bit Intel or AMD processors
- amd64 means 64 bit Intel or AMD processors
See the Slicer4 project in the na-mic.org bug tracker for outstanding issues.
Windows
Mac OSX
A three-button mouse (with scroll wheel) will make slicer much easier to work with.
Linux
Slicer4 will not start if you have Slicer_HOME environment variable initialized to point to a directory different from your Slicer4 installation.
CentOS 5.7 (provided by Matt House)
I’ve just installed the release of Slicer-4.0.gamma-2011-11-27-linux-amd64 on a fully updated CentOS 5.7 machine. After extracting the archive, I was not able to initially run Slicer because of failed dependencies. Slicer claimed that two libraries were missing. This included ‘libssl.so.0.9.8’ and ‘libcrypto.so.0.9.8’. CentOS has these libraries available, but they were present in ‘/lib64/’ with different names and aliases than Slicer expected.
Under Red Hat based distributions, openssl-0.9.8e (note the ‘e’ appended to the name) is provided and the libraries are named ‘libssl.so.0.9.8e’ and ‘libcrypto.so.0.9.8e’. There is also a more generic symlink for each of these libraries named ‘libssl.so.6’ and ‘libcrypto.so.6’, respectively.
As a workaround, I’ve created symlinks to the libraries with Slicer’s expected names (no ‘e’). This allowed me to run Slicer 4, though I still get a warning message stating (in abbreviated form) ‘SlicerQT-real: /lib64/libcrypto.so.0.9.8: no version information available (required by ./lib/Slicer-4.0/libarchive.so.8)’
Fedora 13 (SPL systems)
Creating symlinks on /usr requires root privileges. In the cases when this is not achievable, symlinks can be created in any directory, and LD_LIBRARY_PATH environment variable should be initialized accordingly. Here are the specific steps how this can be done:
> cd ~
> mkdir local
> cd local
> ln -s /usr/lib64/libcrypto.so libcrypto.so.0.9.8
> ln -s /usr/lib64/libssl.so.1.0.0d libssl.so.0.9.8
> setenv LD_LIBRARY_PATH ${HOME}/local
(these exact commands should work for the SPL systems)
