Clare Peters-Libeu wrote:
First off, let me apologize for a really long message.
I'm trying to get Coot running on a 64-bit machine running fedora core 9. I
picked fedora core 9 because many of the graphics libraries required for
Coot are already installed. However, the autobuild script fails when
compiling the clipper libraries. After some research I discovered that
fedora 9 use gcc4.3, but the version of clipper downloaded from Paul
Emsley's site need gcc3.4 to compile (-which is perplexing because I
compiled the clipper libraries from the CCP4 distribution with gcc4.3)
One downloads clipper from Kevin Cowtan's site :)
clipper should compile with gcc4.x (x=anything) AFAIK.
Running the build-it-gtk2-simple appears to build all the packages without
an error. The script exits with an error that the script can't create the
$AUTOBUILD_INSTALLED/python2.5 directory. However, when I look at proper
directory, the directory is indeed there and coot and coot-real are in the
appropriate bin directory.
The logs say that the coot-test in the script failed.
Wow, does it!? I tried to disable the tests of others (i.e. not
developers - it seems I failed). Forget the tests, they will fail
unless you have the (frequently changing) test data sets.
If I start it up
manually, I see the startup image, some verbiage about proper citations, and
then lines about loading a pdb library. It ends with
There are 2 data in /usr/local/share/CCP4/ccp4-6.0.2/lib/data/monomers//g/GD.cif
There are 2 data in /usr/local/share/CCP4/ccp4-6.0.2/lib/data/monomers//t/TD.cif
There are 2 data in /usr/local/share/CCP4/ccp4-6.0.2/lib/data/monomers//u/UR.cif
Reading coordinate file:
/usr/local/share/coot_build/coot-gtk2/share/coot/standard-residues.pdb
PDB file
/usr/local/share/coot_build/coot-gtk2/share/coot/standard-residues.pdb has
been read.
Spacegroup: P 1
Cell: 40.631 109.18 93.243 90 90 90
Illegal instruction
If I build it with the python option, Coot hangs when it displays the coot
image.
Nasty.
OK, back to the non-python version for now. Please try to give us a
debugging report:
$ gdb xxx/bin/coot-real
<stuff happens>
where
thanks.
Have I created a problem by using two different compilers for the libraries
or is this a totally different issue? I've seen posts that refer to similar
behavior that were cured with updating nvidia drivers or messing with
x-windows. Is there a way to tell which it is?
As far as I understand, it is usually OK to use c++ and c in different
compilers - but c++ to c++ in different compilers can cause problems.
____________________________________________________________________
My wrapper script
#!/bin/bash
export AUTOBUILD_INSTALLED=/usr/local/share/autobuild5/coot
export AUTOBUILD_BUILD=/usr/local/share/autobuild5
export LOGS=$AUTOBUILD_BUILD/logs
export NIGHTLY_DEST_DIR=$AUTOBUILD_BUILD
export STABLE_DEST_DIR=$AUTOBUILD_BUILD
export build_coot_prerelease=1
export LD_LIBRARY_DIR=/usr/local/lib:$LD_LIBRARY_DIR
export CC=gcc34
export CXX=g++34
#
# I obtained build-it-gtk-simple using
# wget
http://www.ysbl.york.ac.uk/~emsley/build-logs/build-it-gtk2-simple
#
bash build-it-gtk2-simple > build.log
That seems OK, but I would use the up to date compiler. You suggest
that there is a problem with that. Let's address that problem.
#
#
_____________________________________________________________________
These are the steps that I used to install gcc3.4
Step 1: Install compatibility libraries for programs compiled with earlier
versions of gcc. This may not be strictly necessary for Coot,
That is true.
I'm perplexed. I've download and compiled the clipper libraries using the
CCP4 install script and everything went great with gcc4.3. So there appears
to be a difference between the two set of clipper libraries. As far as I can
tell, the CCP4 installation works fine.
OK, so tell us what is going wrong when you compile clipper with g++-4.3
(send long logs (e.g 0.4-clipper.txt) to: coot-dev at ysbl dot york
dot ac dot uk).
I suspect a linking problem. Let's try to get everything working with
the same compiler: 4.3 or so.
Thanks,
Paul.
