* Fix for _Complex_I problems [not found] ` <87abmbw8du.fsf@ossau.uklinux.net> @ 2008-02-09 18:54 ` Neil Jerram 2008-02-09 19:02 ` Neil Jerram 2008-02-10 10:08 ` Rainer Tammer 0 siblings, 2 replies; 10+ messages in thread From: Neil Jerram @ 2008-02-09 18:54 UTC (permalink / raw) To: Rainer Tammer, Greg Troxel Cc: Ludovic Courtès), Guile Bugs <bug-guile@gnu.org> [-- Attachment #1: Type: text/plain, Size: 364 bytes --] You've both recently reported a compilation problem with _Complex_I, compiling with GCC on Solaris and AIX. My proposed fix for this is attached; please can you review and let me know if you have any comments? (Should I also attach the regenerated ./configure, so you can run that and check that it gives the expected result on your OSs?) Thanks, Neil [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: complex.patch --] [-- Type: text/x-diff, Size: 3370 bytes --] Index: configure.in =================================================================== RCS file: /cvsroot/guile/guile/guile-core/configure.in,v retrieving revision 1.268.2.37 diff -u -r1.268.2.37 configure.in --- configure.in 6 Feb 2008 22:27:59 -0000 1.268.2.37 +++ configure.in 9 Feb 2008 18:43:21 -0000 @@ -715,6 +716,30 @@ [AC_DEFINE(HAVE_CRYPT,1, [Define to 1 if you have the `crypt' function.])]) +# When compiling with GCC on some OSs (Solaris, AIX), _Complex_I doesn't work; +# in the reported cases so far, 1.0fi works well instead. +if test "$ac_cv_type_complex_double" = yes; then + AC_MSG_CHECKING([for i]) + AC_TRY_COMPILE([ +#if HAVE_COMPLEX_H +#include <complex.h> +#endif +complex double z; +],[ +z = _Complex_I; +],[AC_DEFINE(GUILE_I,_Complex_I,[The imaginary unit (positive square root of -1).]) + AC_MSG_RESULT([_Complex_I])],[AC_TRY_COMPILE([ +#if HAVE_COMPLEX_H +#include <complex.h> +#endif +complex double z; +],[ +z = 1.0fi; +],[AC_DEFINE(GUILE_I,1.0fi) + AC_MSG_RESULT([1.0fi])],[ac_cv_type_complex_double=no + AC_MSG_RESULT([not available])])]) +fi + # glibc 2.3.6 (circa 2006) and various prior versions had a bug where # csqrt(-i) returned a negative real part, when it should be positive # for the principal root. Index: libguile/numbers.c =================================================================== RCS file: /cvsroot/guile/guile/guile-core/libguile/numbers.c,v retrieving revision 1.281.2.12 diff -u -r1.281.2.12 numbers.c --- libguile/numbers.c 6 Feb 2008 13:17:49 -0000 1.281.2.12 +++ libguile/numbers.c 9 Feb 2008 18:43:23 -0000 @@ -162,11 +162,12 @@ #endif } - +#if defined (GUILE_I) /* For an SCM object Z which is a complex number (ie. satisfies SCM_COMPLEXP), return its value as a C level "complex double". */ #define SCM_COMPLEX_VALUE(z) \ - (SCM_COMPLEX_REAL (z) + _Complex_I * SCM_COMPLEX_IMAG (z)) + (SCM_COMPLEX_REAL (z) + GUILE_I * SCM_COMPLEX_IMAG (z)) +#endif /* Convert a C "complex double" to an SCM value. */ #if HAVE_COMPLEX_DOUBLE @@ -6011,7 +6012,7 @@ { if (SCM_COMPLEXP (z)) { -#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG +#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG && defined (GUILE_I) return scm_from_complex_double (clog (SCM_COMPLEX_VALUE (z))); #else double re = SCM_COMPLEX_REAL (z); @@ -6045,7 +6046,7 @@ /* Mingw has clog() but not clog10(). (Maybe it'd be worth using clog() and a multiply by M_LOG10E, rather than the fallback log10+hypot+atan2.) */ -#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG10 +#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG10 && defined (GUILE_I) return scm_from_complex_double (clog10 (SCM_COMPLEX_VALUE (z))); #else double re = SCM_COMPLEX_REAL (z); @@ -6077,7 +6078,7 @@ { if (SCM_COMPLEXP (z)) { -#if HAVE_COMPLEX_DOUBLE && HAVE_CEXP +#if HAVE_COMPLEX_DOUBLE && HAVE_CEXP && defined (GUILE_I) return scm_from_complex_double (cexp (SCM_COMPLEX_VALUE (z))); #else return scm_c_make_polar (exp (SCM_COMPLEX_REAL (z)), @@ -6111,7 +6112,7 @@ { if (SCM_COMPLEXP (x)) { -#if HAVE_COMPLEX_DOUBLE && HAVE_USABLE_CSQRT +#if HAVE_COMPLEX_DOUBLE && HAVE_USABLE_CSQRT && defined (GUILE_I) return scm_from_complex_double (csqrt (SCM_COMPLEX_VALUE (x))); #else double re = SCM_COMPLEX_REAL (x); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-09 18:54 ` Fix for _Complex_I problems Neil Jerram @ 2008-02-09 19:02 ` Neil Jerram 2008-02-12 13:22 ` Greg Troxel 2008-02-12 16:32 ` Greg Troxel 2008-02-10 10:08 ` Rainer Tammer 1 sibling, 2 replies; 10+ messages in thread From: Neil Jerram @ 2008-02-09 19:02 UTC (permalink / raw) To: Rainer Tammer, Greg Troxel Cc: Ludovic Courtès), Guile Bugs <bug-guile@gnu.org> [-- Attachment #1: Type: text/plain, Size: 551 bytes --] Neil Jerram <neil@ossau.uklinux.net> writes: > You've both recently reported a compilation problem with _Complex_I, > compiling with GCC on Solaris and AIX. > > My proposed fix for this is attached; please can you review and let me > know if you have any comments? Actually I'd like to make a small change to that; please refer to the new attached patch instead of the previous one. > (Should I also attach the regenerated ./configure, so you can run that > and check that it gives the expected result on your OSs?) (This question still stands.) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: complex.patch --] [-- Type: text/x-diff, Size: 3410 bytes --] Index: configure.in =================================================================== RCS file: /cvsroot/guile/guile/guile-core/configure.in,v retrieving revision 1.268.2.37 diff -u -r1.268.2.37 configure.in --- configure.in 6 Feb 2008 22:27:59 -0000 1.268.2.37 +++ configure.in 9 Feb 2008 19:00:07 -0000 @@ -715,6 +716,30 @@ [AC_DEFINE(HAVE_CRYPT,1, [Define to 1 if you have the `crypt' function.])]) +# When compiling with GCC on some OSs (Solaris, AIX), _Complex_I doesn't work; +# in the reported cases so far, 1.0fi works well instead. +if test "$ac_cv_type_complex_double" = yes; then + AC_MSG_CHECKING([for i]) + AC_TRY_COMPILE([ +#if HAVE_COMPLEX_H +#include <complex.h> +#endif +complex double z; +],[ +z = _Complex_I; +],[AC_DEFINE(GUILE_I,_Complex_I,[The imaginary unit (positive square root of -1).]) + AC_MSG_RESULT([_Complex_I])],[AC_TRY_COMPILE([ +#if HAVE_COMPLEX_H +#include <complex.h> +#endif +complex double z; +],[ +z = 1.0fi; +],[AC_DEFINE(GUILE_I,1.0fi) + AC_MSG_RESULT([1.0fi])],[ac_cv_type_complex_double=no + AC_MSG_RESULT([not available])])]) +fi + # glibc 2.3.6 (circa 2006) and various prior versions had a bug where # csqrt(-i) returned a negative real part, when it should be positive # for the principal root. Index: libguile/numbers.c =================================================================== RCS file: /cvsroot/guile/guile/guile-core/libguile/numbers.c,v retrieving revision 1.281.2.12 diff -u -r1.281.2.12 numbers.c --- libguile/numbers.c 6 Feb 2008 13:17:49 -0000 1.281.2.12 +++ libguile/numbers.c 9 Feb 2008 19:00:08 -0000 @@ -162,11 +162,12 @@ #endif } - +#if defined (GUILE_I) /* For an SCM object Z which is a complex number (ie. satisfies SCM_COMPLEXP), return its value as a C level "complex double". */ #define SCM_COMPLEX_VALUE(z) \ - (SCM_COMPLEX_REAL (z) + _Complex_I * SCM_COMPLEX_IMAG (z)) + (SCM_COMPLEX_REAL (z) + GUILE_I * SCM_COMPLEX_IMAG (z)) +#endif /* Convert a C "complex double" to an SCM value. */ #if HAVE_COMPLEX_DOUBLE @@ -6011,7 +6012,7 @@ { if (SCM_COMPLEXP (z)) { -#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG +#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG && defined (SCM_COMPLEX_VALUE) return scm_from_complex_double (clog (SCM_COMPLEX_VALUE (z))); #else double re = SCM_COMPLEX_REAL (z); @@ -6045,7 +6046,7 @@ /* Mingw has clog() but not clog10(). (Maybe it'd be worth using clog() and a multiply by M_LOG10E, rather than the fallback log10+hypot+atan2.) */ -#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG10 +#if HAVE_COMPLEX_DOUBLE && HAVE_CLOG10 && defined (SCM_COMPLEX_VALUE) return scm_from_complex_double (clog10 (SCM_COMPLEX_VALUE (z))); #else double re = SCM_COMPLEX_REAL (z); @@ -6077,7 +6078,7 @@ { if (SCM_COMPLEXP (z)) { -#if HAVE_COMPLEX_DOUBLE && HAVE_CEXP +#if HAVE_COMPLEX_DOUBLE && HAVE_CEXP && defined (SCM_COMPLEX_VALUE) return scm_from_complex_double (cexp (SCM_COMPLEX_VALUE (z))); #else return scm_c_make_polar (exp (SCM_COMPLEX_REAL (z)), @@ -6111,7 +6112,7 @@ { if (SCM_COMPLEXP (x)) { -#if HAVE_COMPLEX_DOUBLE && HAVE_USABLE_CSQRT +#if HAVE_COMPLEX_DOUBLE && HAVE_USABLE_CSQRT && defined (SCM_COMPLEX_VALUE) return scm_from_complex_double (csqrt (SCM_COMPLEX_VALUE (x))); #else double re = SCM_COMPLEX_REAL (x); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-09 19:02 ` Neil Jerram @ 2008-02-12 13:22 ` Greg Troxel 2008-02-12 21:07 ` Neil Jerram 2008-02-13 7:03 ` Rainer Tammer 2008-02-12 16:32 ` Greg Troxel 1 sibling, 2 replies; 10+ messages in thread From: Greg Troxel @ 2008-02-12 13:22 UTC (permalink / raw) To: Neil Jerram; +Cc: Guile Bugs, ludovic.courtes, Greg Troxel I cannot test on Solaris; I was reporting a problem that a pkgsrc user had. The fix looks like it will work, but I am not comfortable with it. It mucks up the source with local defines to hack around lack of standards compliance. Reading the second diff, there's much less of this. As far as I can tell, C99 says that if complex.h is there then _Complex_I has to work. This is the reason why I'm being cranky about defining around it. I would prefer to use the compile test that you wrote, but to undefine HAVE_COMPLEX_H if it fails, thus falling back to not using the (therefore broken) complex support at all. I had meant to suggest this, and I'm sorry if I didn't manage to do that. Adding a remedial #define _Complex_I 1.0fi to the beginning of numbers.c if _Complex_I weren't defined would seem less objectionable, and also work. Thanks for paying attention to this. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-12 13:22 ` Greg Troxel @ 2008-02-12 21:07 ` Neil Jerram 2008-02-13 7:03 ` Rainer Tammer 1 sibling, 0 replies; 10+ messages in thread From: Neil Jerram @ 2008-02-12 21:07 UTC (permalink / raw) To: Greg Troxel; +Cc: Guile Bugs, ludovic.courtes Greg Troxel <gdt@ir.bbn.com> writes: > Adding a remedial > > #define _Complex_I 1.0fi > > to the beginning of numbers.c if _Complex_I weren't defined would seem > less objectionable, and also work. Just one detail for the record: unfortunately that wouldn't work for GCC on AIX, because there: - complex.h does define _Complex_I: #define _Complex_I __I - the AIX compiler provides __I, so complex.h works with the AIX compiler - GCC does not provide __I, so the setup doesn't work with GCC (but `#ifdef _Complex_I' is still true) Regards, Neil ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-12 13:22 ` Greg Troxel 2008-02-12 21:07 ` Neil Jerram @ 2008-02-13 7:03 ` Rainer Tammer 1 sibling, 0 replies; 10+ messages in thread From: Rainer Tammer @ 2008-02-13 7:03 UTC (permalink / raw) To: Greg Troxel; +Cc: bug-guile, ludovic.courtes Hello Greg, Greg Troxel wrote: > I cannot test on Solaris; I was reporting a problem that a pkgsrc user had. > > The fix looks like it will work, but I am not comfortable with it. It > mucks up the source with local defines to hack around lack of standards > compliance. Reading the second diff, there's much less of this. > > As far as I can tell, C99 says that if complex.h is there then > _Complex_I has to work. This is the reason why I'm being cranky about > defining around it. > > On AIX _Complex_I is working if you use the IBM compiler (inline function). But if you use gcc then you are doomed... > I would prefer to use the compile test that you wrote, but to undefine > HAVE_COMPLEX_H if it fails, thus falling back to not using the > (therefore broken) complex support at all. I had meant to suggest this, > and I'm sorry if I didn't manage to do that. > > Adding a remedial > > #define _Complex_I 1.0fi > > to the beginning of numbers.c if _Complex_I weren't defined would seem > less objectionable, and also work. > > On AIX: complex.h: #define complex _Complex /*. * a constant expression of type const float _Complex with the * value of the imaginary unit. (a number i such that i**2 =-1). * __I is provided by the AIX xlc C99 compiler. * WARNING: DO NOT USE __I DIRECTLY in an application. Always * use _Complex_I . */ #define _Complex_I __I /* * _Imaginary_I should be a constant expression of type * const float _Imaginary with the value of the imaginary unit. * This is optional in C99. * This is not supported in the AIX xlc C99 compiler. */ /*. * C99 requires this definition of the * very common variable "I", to use as a simpler way * to say _Complex_I. Mathematicians who would say * "3i" will now say in C "3 * I". */ #undef I #define I _Complex_I > Thanks for paying attention to this. > > > Bye Rainer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-09 19:02 ` Neil Jerram 2008-02-12 13:22 ` Greg Troxel @ 2008-02-12 16:32 ` Greg Troxel 2008-02-12 20:44 ` Neil Jerram 1 sibling, 1 reply; 10+ messages in thread From: Greg Troxel @ 2008-02-12 16:32 UTC (permalink / raw) To: Neil Jerram Cc: Guile Bugs, ludovic.courtes, =?iso-8859-1?Q?=28Ludovic_Court=E8s=29?=, Greg Troxel Looking over your patch again, I feel quite a bit better about it. It checks for the standard first, and - +#if defined (GUILE_I) /* For an SCM object Z which is a complex number (ie. satisfies SCM_COMPLEXP), return its value as a C level "complex double". */ #define SCM_COMPLEX_VALUE(z) \ - (SCM_COMPLEX_REAL (z) + _Complex_I * SCM_COMPLEX_IMAG (z)) + (SCM_COMPLEX_REAL (z) + GUILE_I * SCM_COMPLEX_IMAG (z)) +#endif really is very close to a remedial define of _Complex_I. So the impact on conforming systems is small, and limited to a reader of the code having to chase the GUILE_I definition. +# When compiling with GCC on some OSs (Solaris, AIX), _Complex_I doesn't work; +# in the reported cases so far, 1.0fi works well instead. I would add # This is a workaround for the failure of these systems to conform to C99. So this all seems ok to me. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-12 16:32 ` Greg Troxel @ 2008-02-12 20:44 ` Neil Jerram 0 siblings, 0 replies; 10+ messages in thread From: Neil Jerram @ 2008-02-12 20:44 UTC (permalink / raw) To: Greg Troxel Cc: Guile Bugs, ludovic.courtes, =?iso-8859-1?Q?=28Ludovic_Court=E8s=29?= Greg Troxel <gdt@ir.bbn.com> writes: > Looking over your patch again, I feel quite a bit better about it. [...] > I would add > > # This is a workaround for the failure of these systems to conform to C99. > > So this all seems ok to me. Hi Greg, Many thanks for your review, thoughts and second thoughts. I agree that it's a good idea to add the extra sentence that you've suggested, so I'll do that now. Regards, Neil ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-09 18:54 ` Fix for _Complex_I problems Neil Jerram 2008-02-09 19:02 ` Neil Jerram @ 2008-02-10 10:08 ` Rainer Tammer 2008-02-11 20:38 ` Neil Jerram 1 sibling, 1 reply; 10+ messages in thread From: Rainer Tammer @ 2008-02-10 10:08 UTC (permalink / raw) To: Neil Jerram; +Cc: bug-guile Hello, Neil Jerram wrote: > You've both recently reported a compilation problem with _Complex_I, > compiling with GCC on Solaris and AIX. > > My proposed fix for this is attached; please can you review and let me > know if you have any comments? > > OK, I have tested the second patch on AIX 6.1 > (Should I also attach the regenerated ./configure, so you can run that > and check that it gives the expected result on your OSs?) > > I had to regenerate the configure scripts with the latest autoconf/automake/libtool/config.guess because of AIX 6.1. This is my configure call: export CONFIG_SHELL=/usr/bin/bash export CONFIG_ENV_ARGS=/usr/bin/bash export CC=gcc export CXX=g++ export PATH=/opt/freeware/bin:$PATH export LDFLAGS=-Wl,-brtl export CFLAGS="-fno-strict-aliasing -D_USE_IRS" ./configure --enable-dynamic-linking --prefix=/opt/freeware --enable-shared --disable-static > configure.log 2>&1 Furthermore I had to fix this: libguile/srfi-14.c: redefined -> #define _GNU_SOURCE -> config.h libguile/posix.c: redefined -> #define _GNU_SOURCE -> config.h libguile/Makefile: @LTLIBINTL@ gets not replaced with -lintl This is the result of the make check: gmake check-TESTS gmake[4]: Entering directory `/daten/source/guile-1.8.3/test-suite/standalone' PASS: test-system-cmds PASS: test-require-extension PASS: test-num2integral PASS: test-round PASS: test-gh PASS: test-asmobs PASS: test-list PASS: test-unwind PASS: test-conversion Backtrace: In unknown file: ?: 117 [resolve-interface (ice-9 debug)] ... ?: 118 (let* (# # # # ...) (and # #) (if # public-i #)) ?: 119* [resolve-module (ice-9 debug)] ?: 120 (let* ((full-name #)) (let* (#) (if already # #))) ?: 121 (let* ((already #)) (if already (if # # already) (begin # #))) ?: 122* [nested-ref #<module (guile) 2006e130> (%app modules ice-9 debug)] ?: 123 [loop #<module (guile) 2006e130> (%app modules ice-9 debug)] ... ?: 124 [loop ... ?: 125* [module-ref #<module (guile) 2006e130> %app #f] ?: 126 (let* ((variable #)) (if (and variable #) (variable-ref variable) ...)) ?: 127* [module-variable #<module (guile) 2006e130> %app] ?: 128 [module-search #<procedure module-local-variable #> # %app] ... ?: 129 (or (fn m v) (loop (module-uses m))) ?: 130* [module-local-variable #<module (guile) 2006e130> %app] ?: 131 (let* ((b #)) (or (and # b) (and # #))) ?: 132* [module-obarray-ref ... ?: 133* [module-obarray #<module (guile) 2006e130>] ?: 134 (if (eq? # #) (struct-ref obj 0) (%record-type-error # obj)) ?: 135* [eq? ... ?: 136* (struct-vtable obj) <unnamed port>: In expression (struct-vtable obj): <unnamed port>: Stack overflow guile --user-srfi=1,10 fails to run FAIL: test-use-srfi ================================== 1 of 10 tests failed Please report to bug-guile@gnu.org ================================== gmake[4]: *** [check-TESTS] Error 1 I am not sure why this fails now ... never had this problem. > Thanks, > Neil > > Bye Rainer ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-10 10:08 ` Rainer Tammer @ 2008-02-11 20:38 ` Neil Jerram 2008-02-12 7:31 ` Rainer Tammer 0 siblings, 1 reply; 10+ messages in thread From: Neil Jerram @ 2008-02-11 20:38 UTC (permalink / raw) To: Rainer Tammer; +Cc: bug-guile Rainer Tammer <tammer@tammer.net> writes: > OK, I have tested the second patch on AIX 6.1 Thanks. From the fact that compile succeeds, I assume the _Complex_I fix was good, so I'll go ahead with committing that. > I had to regenerate the configure scripts with the latest > autoconf/automake/libtool/config.guess because of AIX 6.1. Understood. This is the last thing I want to try to address before we release 1.8.4. > Furthermore I had to fix this: > > libguile/srfi-14.c: redefined -> #define _GNU_SOURCE -> config.h > libguile/posix.c: redefined -> #define _GNU_SOURCE -> config.h > libguile/Makefile: @LTLIBINTL@ gets not replaced with -lintl Were those hidden because the make stopped at numbers.c before? In any case, I think we should probably revisit those after 1.8.4; otherwise there's too much uncertainty about exactly how the auto* steps happened. > <unnamed port>: In expression (struct-vtable obj): > <unnamed port>: Stack overflow Hmm, that happens on Mac Powerbook too. I did want to address this before 1.8.4, but as it's a Scheme-level error only, I now think it's better for us to get 1.8.4 out - so we'll look at this again after the 1.8.4 release. > Bye > Rainer Thanks!, Neil ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Fix for _Complex_I problems 2008-02-11 20:38 ` Neil Jerram @ 2008-02-12 7:31 ` Rainer Tammer 0 siblings, 0 replies; 10+ messages in thread From: Rainer Tammer @ 2008-02-12 7:31 UTC (permalink / raw) To: Neil Jerram; +Cc: bug-guile Hello, Neil Jerram wrote: [...] > Thanks. From the fact that compile succeeds, I assume the _Complex_I > fix was good, so I'll go ahead with committing that. > > OK >> I had to regenerate the configure scripts with the latest >> autoconf/automake/libtool/config.guess because of AIX 6.1. >> > > Understood. This is the last thing I want to try to address before we > release 1.8.4. > > This sounds good. >> Furthermore I had to fix this: >> >> libguile/srfi-14.c: redefined -> #define _GNU_SOURCE -> config.h >> libguile/posix.c: redefined -> #define _GNU_SOURCE -> config.h >> libguile/Makefile: @LTLIBINTL@ gets not replaced with -lintl >> > > Were those hidden because the make stopped at numbers.c before? > > I think this is caused by the new configure tools ... If I run autoreconf I get the following warnings: # autoreconf 2.61a configure.in:76: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:383: AC_USE_SYSTEM_EXTENSIONS is expanded from... ../../lib/autoconf/specific.m4:454: AC_MINIX is expanded from... configure.in:76: the top level configure.in:76: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS configure.in:76: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:383: AC_USE_SYSTEM_EXTENSIONS is expanded from... ../../lib/autoconf/specific.m4:454: AC_MINIX is expanded from... configure.in:76: the top level configure.in:76: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS autoreconf: configure.in: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION configure.in:76: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:383: AC_USE_SYSTEM_EXTENSIONS is expanded from... ../../lib/autoconf/specific.m4:454: AC_MINIX is expanded from... configure.in:76: the top level configure.in:76: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS configure.in:76: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:383: AC_USE_SYSTEM_EXTENSIONS is expanded from... ../../lib/autoconf/specific.m4:454: AC_MINIX is expanded from... configure.in:76: the top level configure.in:76: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS configure.in:76: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:383: AC_USE_SYSTEM_EXTENSIONS is expanded from... ../../lib/autoconf/specific.m4:454: AC_MINIX is expanded from... configure.in:76: the top level configure.in:76: warning: AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS In guile-readline/configure the following part is messed up: PACKAGE_VERSION='-n 1.8.3 ' PACKAGE_STRING='guile-readline -n 1.8.3 ' This should be: PACKAGE_VERSION='-n 1.8.3' PACKAGE_STRING='guile-readline -n 1.8.3' > In any case, I think we should probably revisit those after 1.8.4; > otherwise there's too much uncertainty about exactly how the auto* > steps happened. > > >> <unnamed port>: In expression (struct-vtable obj): >> <unnamed port>: Stack overflow >> > > Hmm, that happens on Mac Powerbook too. I did want to address this > before 1.8.4, but as it's a Scheme-level error only, I now think it's > better for us to get 1.8.4 out - so we'll look at this again after the > 1.8.4 release. > > No problem. > Thanks!, > Neil > > > Bye Rainer ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-02-13 7:03 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <534824.44153.qm@web37914.mail.mud.yahoo.com> [not found] ` <47A031C6.2030106@dpawson.co.uk> [not found] ` <87odb3uguq.fsf@ossau.uklinux.net> [not found] ` <47A18131.3090503@dpawson.co.uk> [not found] ` <871w7wiep3.fsf@ossau.uklinux.net> [not found] ` <87ir15aw7s.fsf@dellish.bordeaux.inria.fr> [not found] ` <87ve50qpms.fsf_-_@ossau.uklinux.net> [not found] ` <874pcjyfas.fsf@dellish.bordeaux.inria.fr> [not found] ` <87abmbw8du.fsf@ossau.uklinux.net> 2008-02-09 18:54 ` Fix for _Complex_I problems Neil Jerram 2008-02-09 19:02 ` Neil Jerram 2008-02-12 13:22 ` Greg Troxel 2008-02-12 21:07 ` Neil Jerram 2008-02-13 7:03 ` Rainer Tammer 2008-02-12 16:32 ` Greg Troxel 2008-02-12 20:44 ` Neil Jerram 2008-02-10 10:08 ` Rainer Tammer 2008-02-11 20:38 ` Neil Jerram 2008-02-12 7:31 ` Rainer Tammer
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).