Unable to build guile

Unable to build guile

[Dwight]

Hi,
   gcc produces two warning messages which cause the compile to stop.
   I removed -Wall for those two routines and continued the build.
   Then I got the following error:
---------------------------------------------------------------------------------------------------------------------
/usr/local/bin/gcc -I/usr/local/include -I/opt/pware/include -D_THREAD_SAFE -g -O2 -Wall -Wmissing-prototypes 
-Werror .libs/guileS.o -I/usr/local/include -I/opt/pware/include -D_THREAD_SAFE -o .libs/guile guile-guile.o 
-L./.libs -lguile -L/usr/local/lib -L/opt/pware/lib -lintl -liconv -lpthread -lc -lpthreads -lgmp -lm 
/usr/local/lib/libltdl.a 
-Wl,-blibpath:/usr/local/lib:/opt/pware/lib:/usr/local/bin/../lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.4:/usr/local/bin/../lib/gcc:/opt/pware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.4:/usr/local/bin/../lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.4/../../..:/opt/pware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.4/../../..:/usr/lib:/lib 

ld: 0711-317 ERROR: Undefined symbol: lt__PROGRAM__LTX_preloaded_symbols
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make[3]: *** [guile] Error 1
make[3]: Leaving directory `/tmp/VIM/guile-1.8.5/libguile'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/VIM/guile-1.8.5/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/VIM/guile-1.8.5'
make: *** [all] Error 2
---------------------------------------------------------------------------------------------------------------------

   I changed the last command to product the following:

---------------------------------------------------------------------------------------------------------------------
(ld): halt 4
(ld): setopt r/o->w
(ld): setopt nodelcsect
(ld): lrgpage 0
(ld): savename .libs/guile
(ld): filelist 14 2
(ld): i /lib/crt0.o
(ld): i /tmp//ccEdFDTO.o
(ld): i .libs/guileS.o
(ld): i guile-guile.o
(ld): lib ./.libs/libguile.a
(ld): lib /usr/local/lib/libintl.a
(ld): lib /usr/local/lib/libiconv.a
(ld): lib /usr/lib/libpthread.a
(ld): lib /usr/lib/libc.a
(ld): lib /usr/local/lib/libgmp.a
(ld): lib /usr/lib/libm.a
(ld): i /usr/local/lib/libltdl.a
(ld): i /usr/local/bin/../lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.4/libgcc.a
(ld): lib /usr/lib/libg.a
LIBRARY: Shared object libguile.a[libguile.so.17]: 2427 symbols imported.
LIBRARY: Shared object libintl.a[libintl.so.8]: 51 symbols imported.
LIBRARY: Shared object libintl.a[libintl.so.3]: 46 symbols imported.
LIBRARY: Shared object libiconv.a[libiconv.so.2]: 12 symbols imported.
LIBRARY: Shared object libiconv.a[shr4.o]: 10 symbols imported.
LIBRARY: Shared object libiconv.a[shr.o]: 11 symbols imported.
LIBRARY: Shared object libpthread.a[shr_comm.o]: 159 symbols imported.
LIBRARY: Shared object libpthread.a[shr_xpg5.o]: 131 symbols imported.
LIBRARY: Shared object libc.a[shr.o]: 2609 symbols imported.
LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported.
LIBRARY: Shared object libc.a[posix_aio.o]: 17 symbols imported.
LIBRARY: Shared object libc.a[aio.o]: 11 symbols imported.
LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported.
LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported.
LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported.
LIBRARY: Shared object libgmp.a[libgmp.so.3]: 394 symbols imported.
LIBRARY: Shared object /usr/local/lib/libltdl.a[libltdl.so.7]: 73 symbols imported.
FILELIST: Number of previously inserted files processed: 14
(ld): exports /usr/lib/libg.exp
EXPORTS: Symbols exported: 4
(ld): initfini _GLOBAL__FI_guile _GLOBAL__FD_guile
(ld): resolve
RESOLVE: 341 of 8341 symbols were kept.
(ld): addgl /usr/lib/glink.o
ADDGL: Glink code added for 30 symbols.
(ld): er full
ld: 0711-318 ERROR: Undefined symbols were found.
         The following symbols are in error:
  Symbol                    Inpndx  TY CL Source-File(Object-File) OR Import-File{Shared-object}
                               RLD: Address  Section  Rld-type Referencing Symbol
  ----------------------------------------------------------------------------------------------
  lt__PROGRAM__LTX_preloaded_symbols [582]   ER RW guile.c(guile-guile.o)
                                    000000d0 .data    R_POS    [568]   <lt__PROGRAM__LTX_preloaded_symbols>
ER: The return code is 8.
ld: 0711-317 ERROR: Undefined symbol: lt__PROGRAM__LTX_preloaded_symbols
collect2: ld returned 8 exit status
---------------------------------------------------------------------------------------------------------------------

   I did a grep trying to find where the symbol was defined and was not able to locate it.
   grep found the symbol in guile-guile.o in the guile-1.8.5/libguile directory.

   What am I doing wrong.

   I am trying to build this on AIX 5.2 using:
	gcc (GCC) 4.2.4
	GNU Make 3.81
	autoconf (GNU Autoconf) 2.63
	m4 (GNU M4) 1.4.12

   It seems that I need the guile library to compile autogen and I believe
that vim also use it.

   I would appreciate some help!

Bye,
Dwight

Re: Unable to build guile

[Ludovic Courtès]

Hi,

Dwight <dcrs6000@aceweb.com> writes:

> ld: 0711-317 ERROR: Undefined symbol: lt__PROGRAM__LTX_preloaded_symbols

Please make sure to use GNU Libtool 1.5.x as we don't support 2.2.x
yet.  That will hopefully fix the problem.

Besides, it would be nice if you could report on your experience
building and testing (with "make check") Guile on AIX.

Thanks,
Ludo'.

Re: Unable to build guile

[Andy Wingo]

On Sun 02 Nov 2008 21:31, ludo@gnu.org (Ludovic Courtès) writes:

> Dwight <dcrs6000@aceweb.com> writes:
>
>> ld: 0711-317 ERROR: Undefined symbol: lt__PROGRAM__LTX_preloaded_symbols
>
> Please make sure to use GNU Libtool 1.5.x as we don't support 2.2.x
> yet.  That will hopefully fix the problem.

FYI, I'm told that the new Ubuntu release uses 2.2 by default. We'll get
a lot more of these if we don't fix this soon. I would poke at fixing
this but Fedora does not ship libtool 2.2.

Cheers,

Andy
-- 
http://wingolog.org/

Re: Unable to build guile

[Dwight]

Hi Ludovic Courtès,


>>>It's libltdl (part of Libtool) that matters, since Libtool (the script)
>>>is otherwise bundled with Guile's tar.gz.  So can you please make sure
>>>Guile is compiled using libltdl from Libtool 1.5.x?  To that end, you
>>>can pass `-I' flags to the compiler, e.g., as follows:
>>>
>>>  $ CPPFLAGS="-I/path/to/libtool/1.5.x/include" ./configure ...
>>
>>  I could not find a libtool include directory.  All I could find
>>is the following.
> 
> 
> You should look for `ltdl.h', which is the public header file of
> libltdl.  You can also look for `libltdl.*', which is the compiled
> `libltdl'.
> 
> Then there should be a `-I' flag for the former and a `-L' flag for the
> latter. 

   I did the following:

# CPPFLAGS="-I/opt/freeware/share/libtool/libltdl" ./configure

remove the -Wall from the compile of numbers.c compiler command and
reran the command

# make

remove the _Wall from the compile of net_db.c compiler command and
reran the command

# make

   Not sure; but I think it got pass the place where it was having
a problem with the unknow symbol.  But I am not sure because I was not
watching the compile.

   However; the make did not complete successfully.  It stopped with the
following: (I typed a make again to see if it would work!  Got the same error message!)
   Any suggestions?

gawk -f ./guile-func-name-check regex-posix.c
(./guile-snarf-docs -DHAVE_CONFIG_H -I.. -I.. -I.. -I/opt/freeware/share/libtool/libltdl -I/usr/local/include 
-I/opt/pware/include -g -O2 -Wall -Wmissing-prototypes -Werror regex-posix.c | \
         ./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc || { rm regex-posix.doc; false; }
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc 
deprecation.doc deprecated.doc discouraged.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc 
evalext.doc extensions.doc feature.doc fluids.doc fports.doc futures.doc gc.doc goops.doc gsubr.doc 
gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.doc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc 
init.doc ioext.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc 
objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc 
random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc 
stackchk.doc stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc srfi-14.doc strorder.doc strports.doc 
struct.doc symbols.doc threads.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc 
weaks.doc ramap.doc unif.doc dynl.doc filesys.doc posix.doc net_db.doc socket.doc regex-posix.doc | 
GUILE="/tmp/VIM/guile-1.8.5/pre-inst-guile" ../scripts/snarf-check-and-output-texi          > 
guile-procedures.texi || { rm guile-procedures.texi; false; }
/bin/sh: 29454 Segmentation fault(coredump)
make[3]: *** [guile-procedures.texi] Error 1
make[3]: Leaving directory `/tmp/VIM/guile-1.8.5/libguile'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/VIM/guile-1.8.5/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/VIM/guile-1.8.5'
make: *** [all] Error 2


*********************************************************************************************************
Error Log entry for this problem:




LABEL:          CORE_DUMP
Date/Time:       Mon Nov  3 18:03:58 PST
Type:            PERM
Resource Name:   SYSPROC
Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED
Detail Data
SIGNAL NUMBER
           11
USER'S PROCESS ID:
        28756
FILE SYSTEM SERIAL NUMBER
            5
INODE NUMBER
        24579
PROCESSOR ID
            1
CORE FILE NAME
/tmp/VIM/guile-1.8.5/libguile/core
PROGRAM NAME
lt-guile
ADDITIONAL INFORMATION
pthread_m 4C
pthread_m 44
scm_threa 28
scm_i_ini 4C
scm_i_wit 100
scm_boot_ 34
main 3C
__start 8C





# find . -name "lt-guile" -print
./libguile/.libs/lt-guile
# /usr/local/bin/file ./libguile/.libs/lt-guile
./libguile/.libs/lt-guile: executable (RISC System/6000 V3.1) or obj module not stripped

Re: Unable to build guile

[Ludovic Courtès]

Hello,

Dwight <dcrs6000@aceweb.com> writes:

>   I did the following:
>
> # CPPFLAGS="-I/opt/freeware/share/libtool/libltdl" ./configure
>
> remove the -Wall from the compile of numbers.c compiler command and
> reran the command

Note that `-Wall' itself is harmless, it's `-Werror' that causes the
compilation to stop.  You can just as well use:

  ... ./configure --disable--error-on-warning

which removes `-Werror'.

> gawk -f ./guile-func-name-check regex-posix.c
> (./guile-snarf-docs -DHAVE_CONFIG_H
> -I.. -I.. -I.. -I/opt/freeware/share/libtool/libltdl
> -I/usr/local/include -I/opt/pware/include -g -O2 -Wall
> -Wmissing-prototypes -Werror regex-posix.c | \
>         ./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc || { rm regex-posix.doc; false; }
> cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc
> chars.doc continuations.doc debug.doc deprecation.doc deprecated.doc
> discouraged.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc
> eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc
> futures.doc gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc
> gc-malloc.doc gc-card.doc guardians.doc hash.doc hashtab.doc hooks.doc
> i18n.doc init.doc ioext.doc keywords.doc lang.doc list.doc load.doc
> macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc
> options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc
> properties.doc random.doc rdelim.doc read.doc root.doc rw.doc
> scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc
> stackchk.doc stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc
> srfi-14.doc strorder.doc strports.doc struct.doc symbols.doc
> threads.doc throw.doc values.doc variable.doc vectors.doc version.doc
> vports.doc weaks.doc ramap.doc unif.doc dynl.doc filesys.doc posix.doc
> net_db.doc socket.doc regex-posix.doc |
> GUILE="/tmp/VIM/guile-1.8.5/pre-inst-guile"
> ../scripts/snarf-check-and-output-texi          >
> guile-procedures.texi || { rm guile-procedures.texi; false; }
> /bin/sh: 29454 Segmentation fault(coredump)

The `guile-snarf-docs' scripts uses Guile, so it's an indication that
the newly built Guile doesn't work.  :-)

Can you try running "./pre-inst-guile" from the Guile build directory?

Also, can you provide a backtrace for the segfault?  Assuming GDB is
available on your platform, something like the following should work:

  $ cd /the/guile/build/dir
  $ gdb libguile/.libs/lt-guile core
  (gdb) bt full

It would also be interesting to see the warnings issued by GCC -Wall.

Thanks in advance,
Ludo'.

Re: Unable to build guile

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Wingo wrote:
> On Sun 02 Nov 2008 21:31, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Dwight <dcrs6000@aceweb.com> writes:
>>
>>> ld: 0711-317 ERROR: Undefined symbol: lt__PROGRAM__LTX_preloaded_symbols
>> Please make sure to use GNU Libtool 1.5.x as we don't support 2.2.x
>> yet.  That will hopefully fix the problem.
>
> FYI, I'm told that the new Ubuntu release uses 2.2 by default. We'll get
> a lot more of these if we don't fix this soon. I would poke at fixing
> this but Fedora does not ship libtool 2.2.
>
> Cheers,
>
> Andy

http://lists.gnu.org/archive/html/guile-devel/2008-05/msg00014.html

already contained a patch for this:


- --- configure.in.old    2008-05-06 23:48:26.000000000 +0200
+++ configure.in        2008-05-06 23:48:26.000000000 +0200
@@ -38,7 +38,7 @@
 ]),
         address@hidden)
 AC_CONFIG_AUX_DIR([build-aux])
- -AC_CONFIG_MACRO_DIR([m4])
+AC_CONFIG_MACRO_DIR([guile-config])
 AC_CONFIG_SRCDIR(GUILE-VERSION)

 AM_INIT_AUTOMAKE([gnu no-define check-news])


Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkQi20ACgkQp/VmCx0OL2yGSQCfdfMTMm1+4rMceDyK+D7H1xoF
yxEAn36n7fOqL3IAlmwK/2eSNRfRsqAC
=Ibey
-----END PGP SIGNATURE-----

Re: Unable to build guile

[Dwight]

Hi Ludovic Courtès,

> Note that `-Wall' itself is harmless, it's `-Werror' that causes the
> compilation to stop.  You can just as well use:
> 
>   ... ./configure --disable--error-on-warning
> 
> which removes `-Werror'.
   OK!  Thanks for the tip!

> The `guile-snarf-docs' scripts uses Guile, so it's an indication that
> the newly built Guile doesn't work.  :-)
> 
> Can you try running "./pre-inst-guile" from the Guile build directory?


# ./pre-inst-guile 2>&1 | tee /tmp/ToMail
ksh: 28668 Segmentation fault(coredump)


LABEL:          CORE_DUMP
Date/Time:       Tue Nov  4 11:09:47 PST
Type:            PERM
Resource Name:   SYSPROC
Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED
Detail Data
SIGNAL NUMBER
           11
USER'S PROCESS ID:
        28668
FILE SYSTEM SERIAL NUMBER
            5
INODE NUMBER
        24576
PROCESSOR ID
            1
CORE FILE NAME
/tmp/VIM/guile-1.8.5/core
PROGRAM NAME
lt-guile
ADDITIONAL INFORMATION
pthread_m 4C
pthread_m 44
scm_threa 28
scm_i_ini 4C
scm_i_wit 100
scm_boot_ 34
main 3C
__start 8C




> Also, can you provide a backtrace for the segfault?  Assuming GDB is
> available on your platform, something like the following should work:
> 
>   $ cd /the/guile/build/dir
>   $ gdb libguile/.libs/lt-guile core
>   (gdb) bt full

# ./pre-inst-guile
Segmentation fault(coredump)
# gdb libguile/.libs/lt-guile core
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"...
ptrace ldinfo: The process does not exist..
(gdb) bt full
#0  0xd004a864 in pthread_mutexattr_init () from /usr/lib/libpthreads.a(shr_xpg5.o)
No symbol table info available.
#1  0xd6dd0bac in scm_threads_prehistory (base=0x2ff21e48) at threads.c:1656
No locals.
#2  0xd6e38b40 in scm_i_init_guile (base=0x0) at init.c:421
No locals.
#3  0xd6dd2fa4 in scm_i_with_guile_and_parent (func=@0xf0bd8764: 0x100a6834, data=0x2ff21ea8, parent=0xd6e37cfc)
     at threads.c:561
         res = (void *) 0xf0bd8764
         base_item = 3846
#4  0xd6e38908 in scm_boot_guile (argc=536910536, argv=0x1, main_func=@0x20009af0: 0, closure=0x8180)
     at init.c:350
         c = {main_func = @0x200018b0: 0x10000458 <inner_main>, closure = 0x0, argc = 1, argv = 0x2ff21f5c}
#5  0x10000414 in main (argc=1, argv=0x2ff21f5c) at guile.c:74
No locals.
(gdb) Quit


> It would also be interesting to see the warnings issued by GCC -Wall.

numbers.c: In function 'guile_ieee_init':
numbers.c:622: warning: dereferencing type-punned pointer will break strict-aliasing rules
numbers.c:645: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[3]: *** [libguile_la-numbers.lo] Error 1


cc1: warnings being treated as errors
net_db.c: In function 'scm_resolv_error':
net_db.c:112: warning: implicit declaration of function 'hstrerror'
make[3]: *** [net_db.lo] Error 1





   Hope this information help.

Bye,
Dwight

Re: Unable to build guile

[Ludovic Courtès]

Hi,

"Marijn Schouten (hkBst)" <hkBst@gentoo.org> writes:

> http://lists.gnu.org/archive/html/guile-devel/2008-05/msg00014.html
>
> already contained a patch for this:
>
>
> --- configure.in.old    2008-05-06 23:48:26.000000000 +0200
> +++ configure.in        2008-05-06 23:48:26.000000000 +0200
> @@ -38,7 +38,7 @@
>  ]),
>          address@hidden)
>  AC_CONFIG_AUX_DIR([build-aux])
> -AC_CONFIG_MACRO_DIR([m4])
> +AC_CONFIG_MACRO_DIR([guile-config])
>  AC_CONFIG_SRCDIR(GUILE-VERSION)

This looks suspicious to me: the only M4 macros contained in
`guile-config' are Guile's own, so I don't understand why adding this
would fix anything.

Thanks,
Ludo'.

Re: Unable to build guile

[Ludovic Courtès]

Hello,

Dwight <dcrs6000@aceweb.com> writes:

> (gdb) bt full
> #0  0xd004a864 in pthread_mutexattr_init () from /usr/lib/libpthreads.a(shr_xpg5.o)
> No symbol table info available.
> #1  0xd6dd0bac in scm_threads_prehistory (base=0x2ff21e48) at threads.c:1656
> No locals.
> #2  0xd6e38b40 in scm_i_init_guile (base=0x0) at init.c:421

It looks like `get_thread_stack_base ()' doesn't work.

Can you run "grep -i pthread_attr_getstack config.h" and "grep -i
pthread_get_stackaddr config.h" from the build directory?

> numbers.c: In function 'guile_ieee_init':
> numbers.c:622: warning: dereferencing type-punned pointer will break strict-aliasing rules
> numbers.c:645: warning: dereferencing type-punned pointer will break strict-aliasing rules

It's surprising that `DINFINITY' and `DQNAN' are declared as ints.  Can
you "rgrep '\(DINFINITY\|DQNAN\)' /usr/include"?

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.

> 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"?

Thanks in advance,
Ludovic.

Re: Unable to build guile

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ludovic � wrote:
> Hi,
>
> "Marijn Schouten (hkBst)" <hkBst@gentoo.org> writes:
>
>> http://lists.gnu.org/archive/html/guile-devel/2008-05/msg00014.html
>>
>> already contained a patch for this:
>>
>>
>> --- configure.in.old    2008-05-06 23:48:26.000000000 +0200
>> +++ configure.in        2008-05-06 23:48:26.000000000 +0200
>> @@ -38,7 +38,7 @@
>>  ]),
>>          address@hidden)
>>  AC_CONFIG_AUX_DIR([build-aux])
>> -AC_CONFIG_MACRO_DIR([m4])
>> +AC_CONFIG_MACRO_DIR([guile-config])
>>  AC_CONFIG_SRCDIR(GUILE-VERSION)
>
> This looks suspicious to me: the only M4 macros contained in
> `guile-config' are Guile's own, so I don't understand why adding this
> would fix anything.
>
> Thanks,
> Ludo'.

The patch is necessary to succesfully run autotools. Rerunning autotools is what
 fixes the problem.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkRtkIACgkQp/VmCx0OL2xFfgCfTBdQtnlBqT0iQZ9eKU7GLxW2
/QsAn1tyOujKd/5kPK63h5f49Dx+o6eN
=QT8F
-----END PGP SIGNATURE-----

Re: Unable to build guile

[Dwight]

Hi Ludovic Courtès,

>>(gdb) bt full
>>#0  0xd004a864 in pthread_mutexattr_init () from /usr/lib/libpthreads.a(shr_xpg5.o)
>>No symbol table info available.
>>#1  0xd6dd0bac in scm_threads_prehistory (base=0x2ff21e48) at threads.c:1656
>>No locals.
>>#2  0xd6e38b40 in scm_i_init_guile (base=0x0) at init.c:421
> 
> 
> It looks like `get_thread_stack_base ()' doesn't work.
> 
> Can you run "grep -i pthread_attr_getstack config.h" and "grep -i
> pthread_get_stackaddr config.h" from the build directory?

# grep -i pthread_attr_getstack config.h
/* Define to 1 if you have the `pthread_attr_getstack' function. */
#define HAVE_PTHREAD_ATTR_GETSTACK 1
/* #undef PTHREAD_ATTR_GETSTACK_WORKS */

# grep -i pthread_get_stackaddr config.h
/* Define to 1 if you have the `pthread_get_stackaddr_np' function. */
/* #undef HAVE_PTHREAD_GET_STACKADDR_NP */


>>numbers.c: In function 'guile_ieee_init':
>>numbers.c:622: warning: dereferencing type-punned pointer will break strict-aliasing rules
>>numbers.c:645: warning: dereferencing type-punned pointer will break strict-aliasing rules
> 
> 
> It's surprising that `DINFINITY' and `DQNAN' are declared as ints.  Can
> you "rgrep '\(DINFINITY\|DQNAN\)' /usr/include"?
   I do not have rgrep; but I did do a grep on /usr/include and /usr/include/sys

# 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


> 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


>>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);

   Hope this information is what you requested.

Bye,
Dwight

Re: Unable to build guile

[Ludovic Courtès]

Hello,

Dwight <dcrs6000@aceweb.com> writes:

> # grep -i pthread_attr_getstack config.h
> /* Define to 1 if you have the `pthread_attr_getstack' function. */
> #define HAVE_PTHREAD_ATTR_GETSTACK 1
> /* #undef PTHREAD_ATTR_GETSTACK_WORKS */
>
> # grep -i pthread_get_stackaddr config.h
> /* Define to 1 if you have the `pthread_get_stackaddr_np' function. */
> /* #undef HAVE_PTHREAD_GET_STACKADDR_NP */

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.

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.

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

>>>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?

Thank you!

Ludo'.

Re: Unable to build guile

[Dwight]

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

Re: Unable to build guile

[Ludovic Courtès]

Hello,

Dwight <dcrs6000@aceweb.com> writes:

> 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?

Alternatively, if you know of a way we could test Guile on that
platform, that would be great.

>>>  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?

I assume the latter since <netdb.h> is already included in `net_db.c'.

Thanks for your perseverance!

Ludo'.

Re: Unable to build guile

[Dwight]

[-- 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 --]

Re: Unable to build guile

[Ludovic Courtès]

Hello,

Dwight <dcrs6000@aceweb.com> writes:

>> 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.

Hmm, can you try another thing in GDB:

  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

Sorry but it's quite tedious to debug remotely.  :-(

> # 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'?

Thanks,
Ludo'.

Re: Unable to build guile

[Dwight]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

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

[-- Attachment #2: netdb.h.gz --]
[-- Type: application/gzip, Size: 4656 bytes --]