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.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
