Hi Ludovic Courtès,
>   b main
>   run -q -c 0
>   b scm_threads_prehistory
>   c
>   whatis scm_i_pthread_mutexattr_recursive
>   p scm_i_pthread_mutexattr_recursive
>   c
> 
> And again:
> 
>   ./libtool --mode=execute gdb ./libguile/guile -x the-new-script
   I just modified the old file so the name did not change.  That is;
I removed all the old stuff and then inserted the above commands.

#  ./libtool --mode=execute gdb ./libguile/guile -x the-script
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-ibm-aix5.2.0.0"...
Breakpoint 1 at 0x100003f8: file guile.c, line 72.

Breakpoint 1, main (argc=4, argv=0x2ff22058) at guile.c:72
72      guile.c: A file or directory in the path name does not exist..
         in guile.c
Breakpoint 2 at 0xd6c7cba4: file threads.c, line 1656.

Breakpoint 2, scm_threads_prehistory (base=0x2ff21f48) at threads.c:1656
1656    threads.c: A file or directory in the path name does not exist..
         in threads.c
type = pthread_mutexattr_t [1]
$1 = {0x0}

Program received signal SIGSEGV, Segmentation fault.
0xd004a864 in pthread_mutexattr_init () from /usr/lib/libpthreads.a(shr_xpg5.o)
(gdb) quit
The program is running.  Exit anyway? (y or n) y



> Sorry but it's quite tedious to debug remotely.  :-(
   I understand.  No problem.
   A VERY long time ago when I was a programmer I used to get
problem reports for people and usually had a hard time duplicating the
problem on our local systems.  Our usualy answer was to upgrade to the
latest version.  ;) :( :)  I worked for a computer company in the
operating system group.

> 
> 
>># grep hstrerror /usr/include/*
>>/usr/include/netdb.h:const char      *hstrerror();
>>/usr/include/netdb.h:const char *    hstrerror(int);
> 
> 
> Can you check whether these declarations are enclosed in an `#ifdef'?
   I am just attaching the file just in case you might need additional information.

   By the way I tried doing what Marijn Schouten suggested to solve the incompatibility
with the libtool package.  That is; I modified the configure.in file like he suggested
and executed the commands he told me to; but libtool 2.2.4 would not work.  In fact,
the configure did not even work.  :( :(

Bye,
Dwight