Hi Kevin,
On Mon, 09 Feb 2009 05:16:23 -0800, Kevin Cowtan wrote:
I can't do it, and I can't figure it out. I keep getting errors like these
at various steps:
/bin/sh: symbol lookup error:
/home/coot/autobuild/coot-pre-release-gtk2-python/lib/libreadline.so.5: undefined symbol: PC
I suspect that LD_LIBRARY_PATH is implicated, but nothing I've tried works.
I've had exactly the same problem on openSUSE 11.1, and according to a hint
that I found here:
http://groups.google.com/group/sage-devel/browse_thread/thread/a711d51717138332?fwc=1
the problem is that libreadline is a dynamically-loaded library required by
/bin/bash, so if you have a locally-built one ahead of the system-provided
one when bash is invoked (e.g. as a subprocess of make or configure) you can
hit some sort of conflict. As for the undefined symbol, it comes from this
bit of code in readline-5.2/terminal.c
#if !defined (__linux__)
# if defined (__EMX__) || defined (NEED_EXTERN_PC)
extern
# endif /* __EMX__ || NEED_EXTERN_PC */
char PC, *BC, *UP;
#endif /* __linux__ */
which looks suspect to me because since we are on a linux system, the symbol
PC should not be defined? However, further down in the same file, PC is
assigned to in code that is not guarded against __linux__ being undefined,
so I am very puzzled about what is going on here.
The openSUSE readline does contain this symbol as undefined:
readelf -s /usr/lib64/libreadline.so
.....
6: 0000000000000000 0 FUNC GLOBAL DEFAULT UND mbrt...@glibc_2.2.5
(2)
7: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND PC
8: 0000000000000000 0 FUNC GLOBAL DEFAULT UND cl...@glibc_2.2.5 (2)
....
but presumably Novell have worked around this in some way.
Anyway, these musings suggest how to get beyond this particular problem. You
do the following to force the loading of the system-provided libreadline.so
in preference to the locally-built one when bash is invoked during the
build:
export LD_PRELOAD=/lib64/libreadline.so.5
although the better solution would probably be to disable Coot's local build
of readline on openSUSE systems. This evironment setting is not needed to
run coot once built, only during the build itself.
On a 64-bit system with NVIDIA drivers installed, you should also do this,
to stop the build attempting to link against 32-bit GL libraries:
export LDFLAGS=-L/usr/X11R6/lib64
(see for example http://forums.slamd64.com/viewtopic.php?f=4&t=1238 )
You can then set the autobuild environment variables and build as described
on http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/COOT:
/bin/bash build-it-gtk2-simple python
Coot itself then builds, but the build script then barfs out with the
following message:
HTTP request sent, awaiting response... 200 OK
Length: 6728787 (6.4M) [application/x-gzip]
Saving to: `/home/pkeller/autobuild//sources/reference-structures.tar.gz'
100%[================================================================================================================>]
6,728,787 961K/s in 7.0s
2009-04-01 16:13:20 (940 KB/s) -
`/home/pkeller/autobuild//sources/reference-structures.tar.gz' saved
[6728787/6728787]
mkdir: cannot create directory
`/home/pkeller/autobuild/coot-Linux-x86_64-welcome-to-gtk2-python/include/python2.6':
No such file or directory
which makes no sense to me:
linux-eysi pkeller/coot> ls -ld
/home/pkeller/autobuild/coot-Linux-x86_64-welcome-to-gtk2-python/include/python2.6
drwxr-xr-x 2 pkeller users 4096 2009-04-01 15:18
/home/pkeller/autobuild/coot-Linux-x86_64-welcome-to-gtk2-python/include/python2.6
I persisted and tried again, and the build-it-gtk2-simple script then
finished, but the resulting installation had some Python-related problem:
pkeller/autobuild> ./coot-Linux-x86_64-welcome-to-gtk2-python/bin/coot
COOT_PREFIX is ./coot-Linux-x86_64-welcome-to-gtk2-python
./coot-Linux-x86_64-welcome-to-gtk2-python/bin/coot-real
Acquiring application resources from
./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/cootrc
INFO:: splash_screen_pixmap_dir
./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/pixmaps
INFO:: Colours file:
./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/colours.def loaded
....
(use-graphics-interface-state)
DEBUG:: stating pydirectory
./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/python
INFO:: loading coot.py from
./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/python/coot.py
Running python script
./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/python/coot.py
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/python/coot.py", line
8, in <module>
import new
ImportError: No module named new
INFO:: coot.py loaded
INFO:: coot_python initialized
INFO loading coot python modules
Running python script
./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/python/coot_load_modules.py
Traceback (most recent call last):
File "<string>", line 1, in <module>
File
"./coot-Linux-x86_64-welcome-to-gtk2-python/share/coot/python/coot_load_modules.py",
line 23, in <module>
import os
ImportError: could not import gobject
...
and further failures to import python modules (including "os" and "sys"),
finishing with:
Traceback (most recent call last):
File "<string>", line 1, in <module>
NameError: name 'sys' is not defined
DEBUG:: in safe_python_command_with_return() pValue is 0
error (not syntax error)
SystemError: PyEval_EvalCodeEx: NULL globals
./coot-Linux-x86_64-welcome-to-gtk2-python/bin/coot: line 124: 17507
Segmentation fault (core dumped) $coot_real $*
coot-exe: "./coot-Linux-x86_64-welcome-to-gtk2-python/bin/coot-real"
coot-version:
/home/pkeller/autobuild/coot-Linux-x86_64-welcome-to-gtk2-python/bin/coot-real
platform:
/bin/uname
core: #f
No core file found. No debugging
This is not helpful.
Please turn on core dumps before sending a crash report
Since the "coredumpsize" resource was set to "unlimited" in this shell, it
is not clear to me how to get a full crash report for this situation,
however it is possible to work around this and start coot by setting:
export PYTHONPATH=/usr/lib64/python
so success (of a rather hacky kind) eventually.
Why was I building coot at all? Certain dialog windows (such as the one
allowing you to accept a real-space refinement) were simply not appearing on
openSUSE 11.1 with many of the binary downloads, and I could not find any
diagnostics to indicate what the problem was. openSUSE 10.3 worked OK, as
did Ubuntu 8.04.
openSUSE 11.1 currently uses the following version of GTK2:
Name : gtk2 Relocations: (not relocatable)
Version : 2.14.4 Vendor: openSUSE
Release : 8.6.2 Build Date: Wed 25 Feb 2009
17:32:29 GMT
whereas openSUSE 10.3 and Ubuntu 8.04 use versions 2.12.0 and 2.12.9
respectively. The good news is that building on openSUSE 11.1 fixed this
particular problem.
Apologies for mixing up several points in a single message, but it is
probably best to put the whole story in one place. Hopefully it will be
useful.
Regards,
Peter.
--
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom
