Checking gnome-guile

Checking gnome-guile

[Ariel Rios]

Can anybody check if the new gnome-guile modules
(ghttp, gdkpixbuf and gal) are linking correctly?
You will need to have fairly recent versions
of these bleeding edge libs.

I'm getting some strange errors and want to know
if these errors are also available in other platforms
or if I am simply doing something stupid.

Is anyone up to the task? =)
Martin?

ariel

"gtk> (use-modules (gnome gal))
13  (or (try-module-linked name) (try-module-autoload name) ...)
14* [try-module-autoload (gnome gal)]
15  (let* (# # # #) (resolve-module dir-hint-module-name #f) (and # #))
    ...
16  (let ((didit #f)) (dynamic-wind (lambda () #) (lambda () #) ...) ...)
17* [dynamic-wind #<procedure ()> #<procedure ()> #<procedure ()>]
18* [#<procedure ()>]
19* (let ((full #)) (if full (begin # #)))
20  (if full (begin (save-module-excursion (lambda () #)) (set! didit
#t)))
21  (begin (save-module-excursion (lambda () #)) (set! didit #t))
22* [save-module-excursion #<procedure ()>]
23  (let (# #) (dynamic-wind # thunk #))
24  [dynamic-wind #<procedure ()> #<procedure ()> #<procedure ()>]
25* [#<procedure ()>]
26* [primitive-load "/usr/local/share/guile/gnome/gal.scm"]
27* [merge-compiled-code "gal_init_glue" "libguilegal"]
28  (cond (gtkconf-using-ltdl #) (#t #))
    ...
29  [dynamic-wind #<procedure ()> #<procedure ()> #<procedure ()>]
30* [#<procedure ()>]
31* [dynamic-call "gal_init_glue" ...
32* [dynamic-link "libguilegal"]
/usr/local/share/guile/gtk/dynlink.scm:19:34: In procedure dynamic-link in
expression (dynamic-link libname):
/usr/local/share/guile/gtk/dynlink.scm:19:34: file not found"

Re: Checking gnome-guile

[Marius Vollmer]

Ariel Rios <ariel@arcavia.com> writes:

> /usr/local/share/guile/gtk/dynlink.scm:19:34: In procedure dynamic-link in
> expression (dynamic-link libname):
> /usr/local/share/guile/gtk/dynlink.scm:19:34: file not found"

I have not tried your code, but let me try one suggestion anyway: it
is often the case that libltdl (which does dynamic linking for Guile
nowadays) tries a lot of files for a library and uses the first that
can be linked successfully.  When a dlopen fails, for whatever reason,
it carries on with its list of filenames to try.  This means that you
always get the error message that corresponds to the last name that
was tried.  So, when a dlopen fails for your lib because some symbols
are undefined, you will still get a "file not found" error because
libltdl just carries on.

This bug has annoyed me quite some time, and I really should fix it...
(libltdl should only try the next name on its list when the previous
one failed with ENOENT.)