[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 ./
form.
Paul.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- dynamic-linking from guile,
Paul . Emsley <=