* Unable to build guile @ 2008-11-01 21:08 Dwight 2008-11-02 20:31 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Dwight @ 2008-11-01 21:08 UTC (permalink / raw) To: bug-guile 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 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> 0 siblings, 2 replies; 17+ messages in thread From: Ludovic Courtès @ 2008-11-02 20:31 UTC (permalink / raw) To: bug-guile; +Cc: Dwight 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-02 20:31 ` Ludovic Courtès @ 2008-11-03 21:01 ` Andy Wingo [not found] ` <490E7842.9040903@aceweb.com> 1 sibling, 0 replies; 17+ messages in thread From: Andy Wingo @ 2008-11-03 21:01 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-guile, Dwight 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/ ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <490E7842.9040903@aceweb.com>]
[parent not found: <87d4hdmbw8.fsf@gnu.org>]
[parent not found: <490F78C1.9020703@aceweb.com>]
[parent not found: <87ljw01lm1.fsf@gnu.org>]
* Re: Unable to build guile [not found] ` <87ljw01lm1.fsf@gnu.org> @ 2008-11-04 2:16 ` Dwight 2008-11-04 11:11 ` Ludovic Courtès 2008-11-04 17:50 ` Marijn Schouten (hkBst) 0 siblings, 2 replies; 17+ messages in thread From: Dwight @ 2008-11-04 2:16 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-guile 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-04 2:16 ` Dwight @ 2008-11-04 11:11 ` Ludovic Courtès 2008-11-04 20:35 ` Dwight 2008-11-04 17:50 ` Marijn Schouten (hkBst) 1 sibling, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2008-11-04 11:11 UTC (permalink / raw) To: bug-guile; +Cc: Dwight 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-04 11:11 ` Ludovic Courtès @ 2008-11-04 20:35 ` Dwight 2008-11-05 9:10 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Dwight @ 2008-11-04 20:35 UTC (permalink / raw) To: ludo; +Cc: bug-guile 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-04 20:35 ` Dwight @ 2008-11-05 9:10 ` Ludovic Courtès 2008-11-05 21:17 ` Dwight 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2008-11-05 9:10 UTC (permalink / raw) To: bug-guile; +Cc: Dwight 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-05 9:10 ` Ludovic Courtès @ 2008-11-05 21:17 ` Dwight 2008-11-06 11:28 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Dwight @ 2008-11-05 21:17 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-guile 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-05 21:17 ` Dwight @ 2008-11-06 11:28 ` Ludovic Courtès 2008-11-07 1:22 ` Dwight 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2008-11-06 11:28 UTC (permalink / raw) To: bug-guile; +Cc: Dwight 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-06 11:28 ` Ludovic Courtès @ 2008-11-07 1:22 ` Dwight 2008-11-08 17:49 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Dwight @ 2008-11-07 1:22 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-guile 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-07 1:22 ` Dwight @ 2008-11-08 17:49 ` Ludovic Courtès 2008-11-09 0:45 ` Dwight 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2008-11-08 17:49 UTC (permalink / raw) To: bug-guile; +Cc: Dwight 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-08 17:49 ` Ludovic Courtès @ 2008-11-09 0:45 ` Dwight 2008-11-09 21:48 ` Ludovic Courtès 0 siblings, 1 reply; 17+ messages in thread From: Dwight @ 2008-11-09 0:45 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-guile [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-09 0:45 ` Dwight @ 2008-11-09 21:48 ` Ludovic Courtès 2008-11-10 2:26 ` Dwight 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2008-11-09 21:48 UTC (permalink / raw) To: bug-guile; +Cc: Dwight 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-09 21:48 ` Ludovic Courtès @ 2008-11-10 2:26 ` Dwight 0 siblings, 0 replies; 17+ messages in thread From: Dwight @ 2008-11-10 2:26 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-guile [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-04 2:16 ` Dwight 2008-11-04 11:11 ` Ludovic Courtès @ 2008-11-04 17:50 ` Marijn Schouten (hkBst) 2008-11-05 8:42 ` Ludovic Courtès 1 sibling, 1 reply; 17+ messages in thread From: Marijn Schouten (hkBst) @ 2008-11-04 17:50 UTC (permalink / raw) To: Dwight; +Cc: bug-guile, Ludovic Courtès -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-04 17:50 ` Marijn Schouten (hkBst) @ 2008-11-05 8:42 ` Ludovic Courtès 2008-11-05 15:05 ` Marijn Schouten (hkBst) 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2008-11-05 8:42 UTC (permalink / raw) To: bug-guile 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Unable to build guile 2008-11-05 8:42 ` Ludovic Courtès @ 2008-11-05 15:05 ` Marijn Schouten (hkBst) 0 siblings, 0 replies; 17+ messages in thread From: Marijn Schouten (hkBst) @ 2008-11-05 15:05 UTC (permalink / raw) To: Ludovic �; +Cc: bug-guile -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2008-11-10 2:26 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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)
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).