[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

dynamic-linking from guile

From: Paul . Emsley
Subject: dynamic-linking from guile
Date: Sat, 2 Jun 2001 17:40:56 +0100
User-agent: SEMI/1.13.7 (Awazu) CLIME/1.13.6 (中ノ庄) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]