Re: ERROR: In procedure dynamic-link:

[Marius Vollmer <mvo@zagadka.ping.de>]

Bo Forslund <bo.forslund@abc.se> writes:

> How is it with libnames?

The function `dynamic-link' is supposed to supply the extension on its
own.  This is the reason you shouldn't specify any.  For example,
Guile will first look for a `libtool archive#' with extension ".la".
Such an archive is a short description file that will then direct the
actual loading of the real shared library.  This might be necessary on
platforms that don't support inter-library dependencies, or have funny
versioning schemes.  Also, not all platforms use ".so".  HP/UX uses
".sl" I think, and Win32 uses ".dll".  So it's better the let Guile
choose the extension.

This does not seem to work for you, however.  What version of Guile
are you using?  Maybe we need to make sure that it includes the right
version of libltdl (the lower level that handles all the dirty bits
about dynamic linking).

Libltdl has been known for producing "file not found" error messages
for just about any kind of error.  You can't, unfortunately, assume
that the real cause is indeed some file not being found.

This should have been fixed already, however, but it could be that the
version of Guile that you are using has not yet picked up that fix.

It might be helpful to use `strace' to find out what files guile or
guile-gtk are really looking for and which are opened successfully.

> So I did this in dynlink.scm
> 
> (define string-append

( Why do you define string-append?  There is a builtin string-append. )

> Then at what used to be /usr/share/guile/gtk/dynlink.scm:19:34:
> (dynamic-call init-func (dynamic-link (string-append libname ".so")))
> 
> Not very elegant but it works.

Which is kinda strange.

It _could_ be that you have a very old version of Guile that doesn't
provide its own extensions lib shared libraries.  That would have to
be Guile 1.3.4 or something.