Re: Unable to build guile

[Dwight <dcrs6000@aceweb.com>]

Hi Ludovic Courtès,

> Can you try out the following GDB script:
> 
>   b main
>   run -q -c 0
>   b get_thread_stack_base
>   c
>   b scm_get_stack_base
>   c
>   finish
>   finish
>   quit
> 
> Save it to a file, say `the-script', `cd' to the top build directory and
> run:
> 
>   ./libtool --mode=execute gdb ./libguile/guile -x the-script
> 
> Then you can post the GDB output here.

# pwd
/tmp/VIM/guile-1.8.5
# pg the-script
b main
run -q -c 0
b get_thread_stack_base
c
b scm_get_stack_base
c
finish
finish
quit
# ./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.
> 
> 
>># grep -E "DINFINITY|DQNAN" *
>>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
>>>(http://hg.savannah.gnu.org/hgweb/octave/file/ec969f3b8955/liboctave/lo-ieee.cc),
>>>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.
>>
>>	http://www-03.ibm.com/systems/p/os/aix/standards/index.html
> 
> 
> 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
variables.
   I check the Open Group site and they do not seem to have updated that
book.

> Anyway, do you have pointers to documentation or standards that describe
> `DQNAN' and `DINFINITY'?  I don't see anything like this at
> opengroup.org.
   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?
   Yes!
   The grep was done on /usr/include and /usr/include/sys
   I even did then on /usr/local/include; but the responce was null.

Bye,
Dwight