OK, I found what was wrong. Guile failed to compile. In fact, autobuilder downloads guile-1.8.5, and that fails to compile on 64-bit Jaunty (but it does on 64-bit Hardy - the difference must be the gcc version). Interestingly, guile-1.8.5 is available from Ubuntu repositories (but if I install it, then this goosh issue comes up unless I manually move goosh.scm to /usr/share/guile/1.8).
I can reproduce the guile compilation problem if I download and try to build guile-1.8.5 separately. The latest version, guile-1.8.6, builds fine on 64-bit Jaunty, so I tried to force the autobuilder to use 1.8.6, by changing this line in build-it-gtk2-simple guile_version=1.8.5 to this guile_version=1.8.6 This worked fine, and the resulting coot binary seems to be working. On Thu, 2009-05-21 at 12:48 -0400, Ed Pozharski wrote: > I am trying to stop being lazy and just build coot for my system (64-bit > Ubuntu Jaunty). I tried autobuilder scripts, which seem to be quite > awesome, but so far fail in my hands. > > First few things were relatively obvious: I had to install the *-dev > packages to get the pkgconfig to work. > > I hit the wall with the GtkGLExt. Then something weird happened - I > turned off compiz and it went past GtkGlExt issue, but I can't reproduce > it - it works now even after I turned the compiz back on. > > Now it tells me that I "Must install goosh for guile". That I can't > figure out how to do - can't find anything in repositories. > > This leads me to a fundamental question - why do I have to tweak my > system and install additional packages (after I installed everything > mentioned as pre-requisites for the autobuilder in the README)? My > understanding of the autobuilding process was that the script downloads > all the dependencies and configures them in autobuild folder. Take this > goosh issue. I do have the "goosh-1.3" folder in the appropriate place, > why does the script fail to find it? This is reminiscent of my earlier > issue when coot binaries were looking for libraries in /usr/lib instead > of just getting them from coot/lib. This again indicates that something > may be wrong with system configuration. > > Any ideas? > > Ed. > > On Tue, 2009-05-12 at 13:22 -0400, Ed Pozharski wrote: > > 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. --
