dynamic-linking from guile

[Paul . Emsley]

Marcus Brinkman writes:

>From here, there are only guile frames.  The dynamic linking seems to be
> handled in scm_dynamik_link, with the meat of it (the os dependant part) in
> sysdep_dynl_link.  Then there seem to be some more layers in guile
> responsible to wrap up the dlopen call in frame #12.  From there on it's
> glibc.  So we can safely say it is a glibc bug.  In fact, after some digging
> in the ChangeLogs and poking around in the glibc source tree, we find in
> sysdeps/mach/bits/libc-lock.h:

[snip recursive functions redefined]

> Because cthreads does not support recursive locks, and we need one here (see
> elf/rtld.c, _dl_load_lock), we get a dead lock.

> In other words, loading shared objects at run time doesn't seem to be
> supported (very well? at all?).

  What is interesting is that the previous line:

(dynamic-link "libncurses.so")
 
  works fine (or at least don't obviously fail):

(dynamic-link "./guile-ncurses.so")

  causes the hang.

    I moved the guile-ncurses.so into /lib, renamed it, but I couldn't pin
    down what it was about that file that made it unloadable.

    The file is created like this:
    gcc -fPIC -Wall -I/local/include -c -o guile-ncurses.o guile-ncurses.c
    gcc -shared -o guile-ncurses.so guile-ncurses.o

    I tried also linking other libraries, libreadline, libpng, and
    they worked without apparent problem, even loading with the ./
    form. 


    Paul.