|
Collaborative Computational Project No. 4 |
 |
|---|
|
|
Collaborative Computational Project No. 4 |
|
|---|
| Home | About CCP4 | CCP4 Projects | Downloads | Documentation | Courses | Developers | CCP4 people |
|---|
The BLT 2.4-10.z rpm on Fedora Extras has a bug which means it does not install bltwish. Dave Love came up with a solution and a patched version of the RPM is available (see below). This has been found to work on Fedora Core 3 and Red Hat Enterprise WS 4.
Install this patched rpm.
rpm -Uvh blt-2.4-11.z.i386.rpm
It could be necessary to create a couple of symbolic links too. If you get a bltwish not found error:
ln -s /usr/bin/bltwish24 /usr/bin/bltwish
If bltwish complains that it can't find libBLT24:
ln -s /usr/lib/blt2.4/libBLT24.so /usr/lib/libBLT24.so
There is an error in the section of the CCP4 installation documentation dealing with the automated installer script for UNIX and Linux platforms, e.g. at http://www.ccp4.ac.uk/dist/INSTALL.html#install_sh.
The documentation refers to a "configure" subdirectory that should be created as part of the installation process, and which should contain the setup files (e.g. ccp4.setup) for the installation.
However this information is no longer correct. The revised text should read:
The script will also generate a setup-scripts subdirectory that contains set-up files for the various packages (i.e. ccp4.setup for the core suite and programs, and ccp4-others.setup for CCP4mg and Coot) for Bourne/Bash shell (in the sh subdirectory of setup-scripts) and C-shell (in the csh subdirectory). To start using the software you should only need to source the appropriate set-up files for your shell.
The installation documentation has been updated for future releases of the suite.
Thanks to Susumu Ichiyama
There exists autotools for building most things in the src and x-windows directories:
"I finished up pretty much everything in src/ (except pdb_extract and phaser) in a day or so, but x-windows/ isn't done yet. The tarball's available at: http://dev.gentoo.org/~spyderous/ccp4-6.0-autotool.tar.bz2 It includes a README file in src/ that describes some caveats I haven't fixed yet, such as mandatory X/tcl/tk support, lack of support for internal lapack, etc. So far, it's pretty much the minimum necessary to get things working; lots more needs to be converted from system/OS tests to feature tests in the source code."
Thanks to Donnie Berkholz who provided the autotools for building.
This was an installation CCP4 on an amd64 using gcc4.1.1:
The automatic install script failed, so I went about and did manual install (static libraries, gfortran).
Things I have changed to get it going:
- in ccp4-6.0.1/src/harvest_app_/pdb_extract/etc/make.platform.gnu4 deleted the -Werror flag (it worked very well, detecting a calculation that will never get used and exiting).
- csh is no longer maintained on gentoo, and install depends on it. I've forced installation of csh, but that didn't work, so I dumped csh again. I then installed tcsh, searched for all csh scripts, and changed #! /bin/csh into #! /bin/tcsh. This seems to do the trick.
This seems to compile everything, and preliminary tests are looking good.
Thanks to Klass Decanniere who made this report
This was an installation CCP4 on an amd64 using gcc4.1.1:
The automatic install script failed, so I went about and did manual install (static libraries, gfortran).
Things I have changed to get it going:
- in ccp4-6.0.1/src/harvest_app_/pdb_extract/etc/make.platform.gnu4 deleted the -Werror flag (it worked very well, detecting a calculation that will never get used and exiting).
- csh is no longer maintained on gentoo, and install depends on it. I've forced installation of csh, but that didn't work, so I dumped csh again. I then installed tcsh, searched for all csh scripts, and changed #! /bin/csh into #! /bin/tcsh. This seems to do the trick.
This seems to compile everything, and preliminary tests are looking good.
Thanks to Klass Decanniere who made this report
The xplot84driver gui is corrupted/does not work on Suse 8.2 and Redhat Enterprise 3.
There is a reported problem with SCALA on Fedora3, the program gets "stuck". This has been traced to the LAPACK routine DSYEV, when the suite is compiled against the system-supplied LAPACK libraries.
Currently the fix is to build the suite using the Netlib LAPACK libraries which are supplied as part of the CCP4 distribution, by specifying the --with-netlib-lapack option of configure when initially building the suite.
For more details, see Jay Painter's page Fedora Core 3.
Thanks to Phil Evans
The CCTBX Python bindings from the executable install of Phaser/CCTBX do not work correctly with SuSe 10. Either use the CCP4 Python binaries too (follow this advice) or compile as follows.
A tested combination which works on SuSe 10 is to select source files for CCP4, Phaser/CCTBX, CHOOCH and TclTkBLT, and the SuSe 9-9.2 executables for Coot and CCP4MG. It is not necessary to install the CCP4 version of Python, but you should ensure you have the SuSe Python development packages installed (see below). If you do install the CCP4 Python (which must be done from source) you should be aware that will have to separately install any non-standard Python modules (e.g. Numeric) for use with the CCP4 version of Python. SuSe 10 comes with version 4 of the GNU compilers and associated libraries so you will need several compatibility packages. Make sure you have installed the packages listed below.
These can be installed using YaST2.
You can then compile and install by sourcing the install.sh script in the CCP4 download archive after setting the FC environment variable to g77 (see the gfortran advice).
Linking against libccp4f.so may fail for some linuces when using gcc4 with gfortran.
Compilation fails on Suse 8.2 system with gcc 3.3. Example error output is below, followed by a workaround.
> ------------------------------------------------------------ > **** Making regex-v2.1 **** > ------------------------------------------------------------ > make[3]: Entering directory `/mntdirect/_scisoft/pxsoft/src/ccp4/ccp4-6.0.0/suse82/ccp4-6.0/src/harvest_app_/pdb_extract/regex-v2.1' > gcc -O -Werror -Wall -DHAVE_STRCASECMP -DINCL_TEMPLATE_SRC -DHAVE_PLACEMENT_NEW -DNO_RANGE_CHECK -I./include -I../include -DPOSIX_MISTAKE -c ./src/regcomp.c -o obj/regcomp.o > src/regcomp.c: In function `freeset': > src/regcomp.c:1061: warning: comparison between signed and unsigned > src/regcomp.c: In function `freezeset': > src/regcomp.c:1092: warning: comparison between signed and unsigned > src/regcomp.c:1095: warning: comparison between signed and unsigned > src/regcomp.c: In function `firstch': > src/regcomp.c:1119: warning: comparison between signed and unsigned > src/regcomp.c: In function `nch': > src/regcomp.c:1139: warning: comparison between signed and unsigned > make[3]: *** [obj/regcomp.o] Error 1 > make[3]: Leaving directory `/mntdirect/_scisoft/pxsoft/src/ccp4/ccp4-6.0.0/suse82/ccp4-6.0/src/harvest_app_/pdb_extract/regex-v2.1' > make[2]: *** [compile] Error 1 > make[2]: Leaving directory `/mntdirect/_scisoft/pxsoft/src/ccp4/ccp4-6.0.0/suse82/ccp4-6.0/src/harvest_app_/pdb_extract' > make[1]: *** [pdb_extract_suite] Error 2 > make[1]: Leaving directory `/mntdirect/_scisoft/pxsoft/src/ccp4/ccp4-6.0.0/suse82/ccp4-6.0/src' > make: *** [srcdir] Error 2 > tarzan1:/scisoft/pxsoft/src/ccp4/ccp4-6.0.0/suse82/ccp4-6.0
The CCP4 Python binaries provided by CCP4 don't work with Suse 10. Running cctbx.python gives a libreadline import error.
Python 2.4.2 (#2, Jan 26 2006, 11:09:53)
[GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
File "/etc/pythonstart", line 7, in ?
import readline
ImportError: libreadline.so.4: cannot open shared object file: No such file or
directory
Suse 10 includes libreadline.so.5, but no libreadline.so.4. Create a link by doing the following (as the root user).
ln -s /lib/libreadline.so.5 /lib/libreadline.so.4
Mosflm compiles but is completely broken by gfortran 4.0. Using the CCP4 5.99.5 patch, I found that CCP4 compiles out of the box with gfortran, gcc4 and g++4. (I found that I had to have CCP4 build its own version of fftw for clipper to compile).
Debian 3.3 Sid (unstable) includes version 4 of the GNU compilers and associated libraries which include gfortran 4.0.3. CCP4 will not compile with this.
gfortran supplanted g77 as of the 4.x release of the GNU compilers. gfortran has the potential advantage that it supports some Fortran-90 features.
CCP4 6.0 will compile under gfortran 4.1 and 4.2. It will not, however, compile using gfortran 4.0. A patch is available that will make most things compile under gfortran 4.0 (but will then break g77 compilation). However, some programs (notably Mosflm) may not run properly.
The current advice (January 2006) is to use an appropriate version of g77 with gcc-4.x. On Suse 10 and Fedora Core 4 this involves installing the appropriate packages (see Suse 10, FC 4, Debian 3.3), then setting the environment variable FC to "g77" before the configure/compile/install of CCP4, or to upgrade gfortran to 4.2. The latest gfortran binaries are available from the gfortran wiki.
Thanks to various users and developers to identify and test solutions to this issue.
Fedora Core 4 comes with version 4 of the GNU compilers and associated libraries. To install a binary version of CCP4 6 make sure you have installed the compatibility packages listed below then select the Fedora Core 1-4 packages from the download pages.
For help compiling CCP4 on these systems see the gfortran advice.
Older advice. The above advice should be sufficient. Tony Pemberton reports a successful installation under FC4, following Jay Painter's instructions for FC3: "I used the suggested GCC-3.3.5 vanilla source. I compiled and installed in /usr/local using the native compiler. Then removed the default gcc rpm (native) using yum remove gcc (also gets rid of other related stuff - dependencies). The installation [of CCP4] was then very straightforward."
The CCP4 6.0 binaries for linux are known not to work with glibc 2.2.5 which comes with this SuSE distribution.
It is recommended that you install the suite from the source code if you are using SuSE 8.1.
There are problems running CCP4 programs when the suite is compiled with the --with-shared-libs option and using the compilers shipped with RH9.
The installation falls over when the ccif installation tries to run the cifdic_to_symtab program. If this is circumvented, then the suite appears to install, but programs such as sfall die with a segmentation fault. This has been observed at least for CCP4 versions 5.0 and 5.0.1. There are no problems when compiling statically, i.e. without the --with-shared-libs option.
This problem has been traced to problems in the gcc compilers. The problems go when RedHat up2date is run and at least these packages are updated:
glibc-2.3.2-27.9.6.i686.rpm glibc-utils-2.3.2-27.9.6.i386.rpm
glibc-common-2.3.2-27.9.6.i386.rpm nptl-devel-2.3.2-27.9.6.i686.rpm
glibc-devel-2.3.2-27.9.6.i386.rpm nscd-2.3.2-27.9.6.i386.rpm
glibc-profile-2.3.2-27.9.6.i386.rpm
I am writing about a minor hassle when installing CCP4-5.0.1 on Debian Woody systems which is a fault of Debian and NOT CCP4! I installed CCP4-5.0.1 on a Debian Woody (3.0) system and got an error complaining about a missing libg2c.so.0. This package does not appear to be in the current Stable Debian distro despite installed g77/f77/gcc/fortran libs etc.
This can be fixed by installing the debian package libg2c0
from either Testing:
http://packages.debian.org/testing/libs/libg2c0
Or Unstable:
http://packages.debian.org/unstable/libs/libg2c0
You probably know about this already but I just wanted to let you know in case you have any Debian users Emailing you in the future with this problem.
Thanks to Tom Caradoc-Davies
Sun, Alpha and Intel compilers may complain about \' to write quote in line 179 of mtztona4.f. I believe '''' is the correct Fortranic way of doing it (this is used extensively in refmac). \' is probably a widely-accepted extension.
Reports are coming in of CCP4 running successfully on the Fedora platform. In particular, the RedHat 9 binaries distributed for CCP4 release 5 apparently work OK.
The automatic download script download-5.0.1.sh won't work because the OS version is not found correctly.
The script can be edited after line 215 to add "os_version=9" so that it looks like:
...
binsystem="linux"
# For Red Hat systems try to locate a version
if test -f /etc/redhat-release; then
# Get the os version from the redhat file
os_version=`cat /etc/redhat-release | cut -d" " -f5`
else
# Default to the earlier version
os_version=8.0
fi
os_version=9 <-- Add this line
os_version="RedHat${os_version}"
;;
SunOS)
...
Firstly, you need to ensure that you have the following packages installed - some will be there by default but I'm trying to cover all bases here!
You can use "yast" to install these (probably what I would do) or redhat-config-packages in the case of redhat linux.
Once you have these installed, download or get hold of the latest tarball of CCP4 (ccp4-5.0.1.tar.gz at the time of writing) and decide where you want this installed - for instance /opt/xtal
If the machine is a laptop or PC with low-ish resolution (1024x768) the Mosflm GUI will be "too big" for the screen - but we can fix this!
cd $CCP4/x-windows/Mosflm ./to_small.csh
There is a reported problem when compiling cciflib.f under Linux Red Hat 6.0, giving an error of the form:
size of file /ccp4/lib/src/cciflib.f is smaller or equal to given size
of 1433572 !
make[1]:***[libccp4.a(cciflib.o)]Error1
make:***[libdir] Error 2
New versions of the cif configure and Makefile.in files are available on the CCP4 prerelease server (in the subdirectory ccif). Replace the existing files in $CCP4/lib/ccif, then run make realclean before re-running the main configure script (i.e. in $CCP4) and try make again.