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.
--
|