Ludovic Courtès,

>>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
>>Function "get_thread_stack_base" not defined.
>>
>>Program received signal SIGSEGV, Segmentation fault.
>>0xd004a864 in pthread_mutexattr_init () from /usr/lib/libpthreads.a(shr_xpg5.o)
>>Breakpoint 2 at 0xd6c70efc: file gc_os_dep.c, line 1937.
>>
>>Program terminated with signal SIGSEGV, Segmentation fault.
>>The program no longer exists.
>>/tmp/VIM/guile-1.8.5/the-script:7: Error in sourced command file:
>>The program is not running.
>>(gdb) quit
> 
> 
> Hmm, that's not very helpful.  Could you try finding out what it is that
> determines that the stack base is NULL?
    I do not understand what you are asking.
    If you are refering to what happens when a program ask for space.
I assume that the call to ask for space is returning a no space available flag.
I assume it is a system function that is determining if their is any stack space
available.  NOTE:  To run out of stack space would seem to indicate a loop of some
kind.  I have allocate 67,088,384 of stack space.  I have also allocate 268,435,456
for data space.

> Alternatively, if you know of a way we could test Guile on that
> platform, that would be great.
   I know of no way to access this system.

>>>> I did a grep on /usr/include and /usr/include/sys
>>>>
>>>># grep hstrerror *
>>>>netdb.h:const char      *hstrerror();
>>>>netdb.h:const char *    hstrerror(int);
>>>
>>>
>>>Is that under /usr/include or /usr/include/sys?
>>
>>  Yes!
> 
> 
> I mean, was it /usr/include/netdb.h or /usr/include/sys/netdb.h?

# grep hstrerror /usr/include/*
/usr/include/netdb.h:const char      *hstrerror();
/usr/include/netdb.h:const char *    hstrerror(int);

# grep hstrerror /usr/include/sys/*

# grep hstrerror /usr/local/include/*

# grep hstrerror /usr/local/include/sys/*
grep: 0652-033 Cannot open /usr/local/include/sys/*.

# grep hstrerror /opt/freeware/include/*

# grep hstrerror /opt/freeware/include/sys/*
grep: 0652-033 Cannot open /opt/freeware/include/sys/*.


--------------------------------------------------------------------------------------------
  > It's surprising that `DINFINITY' and `DQNAN' are declared as ints.  Can
  > you "rgrep '\(DINFINITY\|DQNAN\)' /usr/include"?
    I did a little more searching and I have determined that
these two symbols are not defined in the gcc 4.2.4 districution.  That is;
when I did a grep on:

$ grep -E "DINFINITY|DQNAN" /usr/local/include/c++/4.2.4/tr1/*

    They were not found.  However; the float.h and the math.h files
are in the distribution.

$ ls -la /usr/local/include/c++/4.2.4/tr1/float.h
-rw-r--r--   1 root     system         1551 Jun 11 14:23 /usr/local/include/c++/4.2.4/tr1/float.h
$ ls -la /usr/local/include/c++/4.2.4/tr1/math.h
-rw-r--r--   1 root     system         2846 Jun 11 14:23 /usr/local/include/c++/4.2.4/tr1/math.h



$ grep -E "DINFINITY|DQNAN" /usr/include/*
/usr/include/float.h:#define DINFINITY _DBLINF
/usr/include/float.h:   extern  unsigned   int DQNAN[2];
/usr/include/float.h:#define DBL_QNAN   (*((double *) (DQNAN)))
/usr/include/math.h:#define DINFINITY _DBLINF
$ grep -E "DINFINITY|DQNAN" /usr/include/sys/*
$ grep -E "DINFINITY|DQNAN" /opt/freeware/include/*

The attachment has a copy of the both float.h and math.h files.
I have also attached the config.log and config.h files.


# pwd
/tmp/VIM/guile-1.8.5/libguile
# grep -E "DINFINITY|DQNAN" *.h
# cd ../
# grep -E "DINFINITY|DQNAN" *.h
config.h:/* Define to 1 if you have the `DINFINITY' function. */
config.h:/* #undef HAVE_DINFINITY */
config.h:/* Define to 1 if you have the `DQNAN' function. */
config.h:/* #undef HAVE_DQNAN */


------------------------------------------------------------------------------------------------
Don't know if it makes any difference; but I have found a copy of Guile 1.6 installed in the
/usr/local directory.

Bye,
Dwight