From: Dwight <dcrs6000@aceweb.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: bug-guile@gnu.org
Subject: Re: Unable to build guile
Date: Sat, 08 Nov 2008 16:45:02 -0800 [thread overview]
Message-ID: <4916328E.9090104@aceweb.com> (raw)
In-Reply-To: <87fxm2az1c.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3978 bytes --]
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
[-- Attachment #2: HeaderLFN.tar.gz --]
[-- Type: application/gzip, Size: 18009 bytes --]
next prev parent reply other threads:[~2008-11-09 0:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-01 21:08 Unable to build guile Dwight
2008-11-02 20:31 ` Ludovic Courtès
2008-11-03 21:01 ` Andy Wingo
[not found] ` <490E7842.9040903@aceweb.com>
[not found] ` <87d4hdmbw8.fsf@gnu.org>
[not found] ` <490F78C1.9020703@aceweb.com>
[not found] ` <87ljw01lm1.fsf@gnu.org>
2008-11-04 2:16 ` Dwight
2008-11-04 11:11 ` Ludovic Courtès
2008-11-04 20:35 ` Dwight
2008-11-05 9:10 ` Ludovic Courtès
2008-11-05 21:17 ` Dwight
2008-11-06 11:28 ` Ludovic Courtès
2008-11-07 1:22 ` Dwight
2008-11-08 17:49 ` Ludovic Courtès
2008-11-09 0:45 ` Dwight [this message]
2008-11-09 21:48 ` Ludovic Courtès
2008-11-10 2:26 ` Dwight
2008-11-04 17:50 ` Marijn Schouten (hkBst)
2008-11-05 8:42 ` Ludovic Courtès
2008-11-05 15:05 ` Marijn Schouten (hkBst)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4916328E.9090104@aceweb.com \
--to=dcrs6000@aceweb.com \
--cc=bug-guile@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).