[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unable to build guile

From: Dwight
Subject: Re: Unable to build guile
Date: Thu, 06 Nov 2008 17:22:07 -0800
User-agent: Mozilla/5.0 (X11; U; AIX 5.2; en-US; rv: Gecko/20070301

Hi Ludovic Courtès,

Can you try out the following GDB script:

  b main
  run -q -c 0
  b get_thread_stack_base
  b scm_get_stack_base

Save it to a file, say `the-script', `cd' to the top build directory and

  ./libtool --mode=execute gdb ./libguile/guile -x the-script

Then you can post the GDB output here.

# pwd
# pg the-script
b main
run -q -c 0
b get_thread_stack_base
b scm_get_stack_base
# ./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
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

The goal is to understand which part of the code is used to determine
the stack base, and what it returns.

float.h:#define DINFINITY _DBLINF
float.h:        extern  unsigned   int DQNAN[2];
float.h:#define DBL_QNAN        (*((double *) (DQNAN)))
math.h:#define DINFINITY _DBLINF

OK, they are truly declared as ints, which truly breaks strict aliasing
rules.  Then we should either compile that file with
`-fno-strict-aliasing' or not use `-Werror'.

Our code appears to be based on that of Octave
which (erroneously) assumes that these variables are only used on OSF.

 AIX is supposed to be compliant with the latest OSF specifications!
If you like you can check out the link below to get more information
about AIX compatability/compliance with UNIX standards.


I am roughly assuming OSF == Tru64 (aka. OSF/1).  I don't see "OSF"
listed in the above page.  According to
http://en.wikipedia.org/wiki/Open_Software_Foundation, OSF is was merged
with the Open Group.
  I believe that is correct.
  It has been over 10 years since I had to deal with this kind of thing.
  There used to be a book called "Go Solo" that had all the standards
and stuff in it.  I have the second version; but could not find those
  I check the Open Group site and they do not seem to have updated that

Anyway, do you have pointers to documentation or standards that describe
`DQNAN' and `DINFINITY'?  I don't see anything like this at
  No I do not.

net_db.c: In function 'scm_resolv_error':
net_db.c:112: warning: implicit declaration of function 'hstrerror'

Can you also "rgrep hstrerror /usr/include"?

 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?
  The grep was done on /usr/include and /usr/include/sys
  I even did then on /usr/local/include; but the responce was null.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]