Didn't help. It must have something to do with my configuration. I have no problems on other machines running Hardy.
Which executable actually requires this library? I put "ldd $coot_real" into the xxx/bin/coot script, and it does list many libraries in xxx/lib properly. However, the one in question is not listed (in fact, coot also complains about canberra-gtk-module, libgiogconf, libgvfsdbus, libgioremote-volume-monitor, but these are perhaps not critical so it does not crash). This may be irrelevant, but I made the following observations: - when coot crashes, it says "ERROR: In procedure dynamic-link:" - when I look in the source, the only place which has these very words (i.e. dynamic-link) is in scheme/my-readline.scm - it says (dynamic-link "libguilereadline-v-12"))) - libguilereadline-v-12 is in guile-1.6-libs, not 1.8 - moreover, coot/lib has libguilereadline-v-17, not 12 - there is /usr/lib32/libguilereadline-v-17, but not 12 I tried to remove/reinstall both guile-1.6-libs and guile-1.8-libs, and it didn't help. Ed. On Tue, 2009-05-12 at 00:34 +0100, Paul Emsley wrote: > Ed Pozharski wrote: > > After recent upgrade to Ubuntu 9.04, coot binaries that worked fine > > before started reporting the "ELFCLASS64" error when loading a > > particular library, namely /usr/lib/libguile-srfi-srfi-1-v-3.so.3. > > > > I understand that the real root of this problem is my bizarre obsession > > with installing 64-bit Linux and then being too lazy to compile coot > > from source and instead trying to use 32-bit coot binaries. To resolve > > the ELFCLASS64 issue, I downloaded guile1.8 32-bit debian package from > > ubuntu repositories and placed libraries into /usr/lib32. That, of > > course, didn't help and I had to redirect the symbolic link in /usr/lib > > to /usr/lib32. > > > OK, try this: > > in your xxx/bin/coot script, > > after the line > > export LD_LIBRARYN32_PATH > > add: > > LTDL_LIBRARY_PATH=$COOT_PREFIX/lib > export LTDL_LIBRARY_PATH > > > Paul. --
