Re: [COOT] ELFCLASS64
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. --
[COOT] ELFCLASS64
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. Now coot runs fine, but this is an ugly fix, not to mention that it may cost me down the road when some 64-bit application discovers that I substituted the library. At the same time, I see that $COOT_PREFIX/lib contains all the libraries, and so my question is why coot tries to load libraries from /usr/lib? Should I uninstall guile via synaptic (I am not sure why I installed it in the first place)? I'll be glad to provide further details. I also tried 64-bit binaries (rev. 1998, rhel-4-python-gtk2), but those crash anytime I try to load an MTZ file (fftw: BUG in executor: invalid plan). --
Re: [COOT] ELFCLASS64
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. Now coot runs fine, but this is an ugly fix, not to mention that it may cost me down the road when some 64-bit application discovers that I substituted the library. At the same time, I see that $COOT_PREFIX/lib contains all the libraries, and so my question is why coot tries to load libraries from /usr/lib? Should I uninstall guile via synaptic (I am not sure why I installed it in the first place)? Very curious. AFAIU the libguile-srfi-srfi are loaded at runtime (probably for some string function). I would have thought that they should load from the installation directory (rather than the system one). How curious. (And, yes, it is ugly.) Well, I'll be over your way in a couple of weeks, if we don't get it sorted out now, we should try to find some time then. Paul.
