Re: [PATCH] Fix exit status of signal handlers in shell scripts
Ralf Wildenhues asked: What system and shell (version?) were your tests done on? I could reproduce Dmitry's tests, with 'sleep 1' instead of 'sleep 0.01'. $ for i in `seq 0 9`; do sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' pid=$! sleep 1 kill -TERM -$pid wait $pid; done [1] 29718 Beendet [1]+ Exit 143sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 29968 Beendet [1]+ Exit 143sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 30546 [1]+ Exit 1 sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 31188 Beendet [1]+ Exit 143sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 31867 [1]+ Donesh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 32547 [1]+ Exit 1 sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 764 Beendet [1]+ Exit 143sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 1406 Beendet [1]+ Exit 143sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 2060 [1]+ Donesh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' [1] 2751 Beendet [1]+ Exit 143sh -c 'trap exit \$? TERM; while /bin/true; do /bin/false; done' $ uname -srm Linux 2.6.25.20-0.5-default x86_64 $ sh -c 'echo $BASH_VERSION' 3.2.39(1)-release What are the other cases you mention, where no process was terminated by the signal, but the signal delivered somewhere nonethess? When I run $ while /bin/true; do /bin/true; done and I want to interrupt it with Ctrl-C, sometimes I have to press Ctrl-C twice: $ while /bin/true; do /bin/true; done ^C $ while /bin/true; do /bin/true; done ^C^C Similarly with a 'trap' handler installed: $ (trap 'echo caught SIGINT; exit 130' 2; while /bin/true; do /bin/true; done) ^Ccaught SIGINT $ (trap 'echo caught SIGINT; exit 130' 2; while /bin/true; do /bin/true; done) ^C^Ccaught SIGINT Bruno
Re: [PATCH] Fix exit status of signal handlers in shell scripts
Jim Meyering wrote: Imagine that the first 10 tests pass, then each of the remaining ones is killed via e.g., SIGHUP. ... a naive search for FAIL: in the build output would find nothing. Yes, and it should be this way, IMO. Each time a user sees a FAIL:, he should be encouraged to investigate. Whereas in the gettext test suite, often when I sent SIGINTs, I saw some tests fail without explanation. (This was due to a missing 'exit' statement in the trap handler, but it would be the same if there was an 'exit 1' in the trap handler.) I guessed that the FAIL report was due to the SIGINT and did not investigate. But I don't think this attitude should be encouraged. Similarly, when I get reports from Nelson Beebe with lots of failing tests, I don't want to spend time on fake failures that were due to, maybe, a shutdown of his virtual machine or something like this. The final result would be highly misleading: All 10 tests passed (300 tests were not run) But before this final result, you would see 300 times Skipping test: caught fatal signal SKIP: test-foo1 Skipping test: caught fatal signal SKIP: test-foo2 Skipping test: caught fatal signal SKIP: test-bar ... That should be enough of an explanation, no? And it will tell us that there's no gnulib bug to investigate. Bruno
Re: [PATCH] Fix exit status of signal handlers in shell scripts
On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote: * Dmitry V. Levin wrote on Sat, Jan 30, 2010 at 08:12:01PM CET: There is a comment about shell signal handlers in gnulib-tool saying that The value of $? is 128 + signal number and is set before the trap-registered command is run. Unfortunately, this comment is wrong, and it seems to be a widespread misunderstanding. The GNU Autoconf manual says that it is widely admitted that when entering the trap `$?' should be set to the exit status of the last command run before the trap. In case of signal handler, the exit status of the last command run before the trap might be 128 + signal number, this usually happens when the last command before the trap was a process terminated by signal. In other cases, the value of $? may be arbitrary. Sometimes it's quite hard to guess this value due to race conditions. Here is an example of such race condition where the value of $? takes one of 3 different values: 0, 1 and 143: Can you please explain whose fault this is? Is that a kernel issue, a shell issue, or expected behavior given a POSIX system? It is expected behaviour. What system and shell (version?) were your tests done on? I tested my example with ash, bash and zsh on a GNU/Linux system. What are the other cases you mention, where no process was terminated by the signal, but the signal delivered somewhere nonethess? A moment when the signal can be delivered to the shell process is not necessarily the moment when an external command is executed. The signal can be delivered when a builtin is executed, or even when nothing is executed yet. In this case, the exit status of the last command run before the trap has nothing related to the just delivered signal. Here is another example of race to illustrate the case: $ for i in `seq 0 9`; do sh -c 'trap exit \$? TERM; while true; do false; done' pid=$! sleep 0.01 kill -TERM -$pid wait $pid; done [1] 9770 [1]+ Donesh -c 'trap exit \$? TERM; while true; do false; done' [1] 9772 [1]+ Donesh -c 'trap exit \$? TERM; while true; do false; done' [1] 9774 [1]+ Donesh -c 'trap exit \$? TERM; while true; do false; done' [1] 9776 [1]+ Exit 1 sh -c 'trap exit \$? TERM; while true; do false; done' [1] 9778 [1]+ Donesh -c 'trap exit \$? TERM; while true; do false; done' [1] 9780 [1]+ Exit 1 sh -c 'trap exit \$? TERM; while true; do false; done' [1] 9782 [1]+ Exit 1 sh -c 'trap exit \$? TERM; while true; do false; done' [1] 9784 [1]+ Exit 1 sh -c 'trap exit \$? TERM; while true; do false; done' [1] 9786 [1]+ Donesh -c 'trap exit \$? TERM; while true; do false; done' [1] 9788 [1]+ Exit 1 sh -c 'trap exit \$? TERM; while true; do false; done' In this example, both true and false are shell builtins, and no external commands are executed. There are no process to be terminated by signal, so the value of $? on entrance to the trap can be either 0 or 1. -- ldv pgpAZHO5Y10Yz.pgp Description: PGP signature
Re: [PATCH] Fix exit status of signal handlers in shell scripts
* Dmitry V. Levin wrote on Sun, Jan 31, 2010 at 01:04:01PM CET: On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote: Can you please explain whose fault this is? Is that a kernel issue, a shell issue, or expected behavior given a POSIX system? It is expected behaviour. What are the other cases you mention, where no process was terminated by the signal, but the signal delivered somewhere nonethess? A moment when the signal can be delivered to the shell process is not necessarily the moment when an external command is executed. The signal can be delivered when a builtin is executed, or even when nothing is executed yet. In this case, the exit status of the last command run before the trap has nothing related to the just delivered signal. Thanks for the explanation. As I understand SUSv3, the same should hold for builtin commands as for external ones. But I agree that nothing may be executed, and there is no limitation for $? then. However, SIGINT should not cause 128+TERM, so it would be more precise to exit with a status that reflected the actual signal given, similar to how configure scripts adjust the per-signal trap, for the scripts which have more than one signal trapped. Thanks, Ralf
Re: [PATCH] Fix exit status of signal handlers in shell scripts
Hi Bruno, thanks for the additional information. * Bruno Haible wrote on Sun, Jan 31, 2010 at 12:32:06PM CET: Ralf Wildenhues asked: What are the other cases you mention, where no process was terminated by the signal, but the signal delivered somewhere nonethess? When I run $ while /bin/true; do /bin/true; done and I want to interrupt it with Ctrl-C, sometimes I have to press Ctrl-C twice: $ while /bin/true; do /bin/true; done ^C $ while /bin/true; do /bin/true; done ^C^C Are you saying that this too is expected behavior? As far as I understood now, the above is a separate issue, and a bug, either in the shell or the kernel/libc, no? Similarly with a 'trap' handler installed: $ (trap 'echo caught SIGINT; exit 130' 2; while /bin/true; do /bin/true; done) ^Ccaught SIGINT $ (trap 'echo caught SIGINT; exit 130' 2; while /bin/true; do /bin/true; done) ^C^Ccaught SIGINT Thanks, Ralf (don't have my copy of APUE here right now)
Re: [Bug-tar] getline() differences FreeBSD / GNU libc
Eric Blake wrote:
FreeBSD is buggy. Rewording the POSIX requirement slightly: if lineptr is
NULL, then it is irrelevant that linecapp is non-zero.
I agree.
Gnulib needs to work around this portability flaw, and guarantee a working
getline implementation even on fBSD, at which point, your patch to tar to
explicitly initialize bufsize to 0 is unnecessary.
Implemented as follows. Since I don't have access to a machine with FreeBSD 8.0,
I would appreciate if someone could test this on FreeBSD 8.0:
$ ./gnulib-tool --create-testdir --dir=/tmp/testdir --with-tests getline
$ cd /tmp/testdir
$ ./configure CPPFLAGS=-Wall
# What is the configure output regarding getline and getdelim here?
$ make; make check
Bruno
2010-01-31 Bruno Haible br...@clisp.org
Work around getline() bug on FreeBSD 8.0.
* m4/getline.m4 (gl_FUNC_GETLINE): Also test result for a NULL buffer
and a non-zero size.
* tests/test-getline.c (main): Likewise.
* doc/posix-functions/getline.texi: Mention the FreeBSD bug.
Reported by Dennis noord...@cs.helsinki.fi via Eric Blake.
--- doc/posix-functions/getline.texi.orig Sun Jan 31 17:20:48 2010
+++ doc/posix-functions/getline.texiSun Jan 31 16:49:18 2010
@@ -17,6 +17,10 @@
@item
Some platforms provide a function by this name but with the wrong
signature, for example in -linet.
+...@item
+This function crashes when passed a pointer to a NULL buffer together with a
+pointer to a non-zero buffer size on some platforms:
+FreeBSD 8.0.
@end itemize
Portability problems not fixed by Gnulib:
--- m4/getline.m4.orig Sun Jan 31 17:20:48 2010
+++ m4/getline.m4 Sun Jan 31 17:07:24 2010
@@ -1,4 +1,4 @@
-# getline.m4 serial 20
+# getline.m4 serial 21
dnl Copyright (C) 1998-2003, 2005-2007, 2009-2010 Free Software Foundation,
dnl Inc.
@@ -24,26 +24,39 @@
gl_getline_needs_run_time_check=no
AC_CHECK_FUNC([getline],
-dnl Found it in some library. Verify that it works.
-gl_getline_needs_run_time_check=yes,
-am_cv_func_working_getline=no)
+[dnl Found it in some library. Verify that it works.
+ gl_getline_needs_run_time_check=yes],
+[am_cv_func_working_getline=no])
if test $gl_getline_needs_run_time_check = yes; then
AC_CACHE_CHECK([for working getline function],
[am_cv_func_working_getline],
-[echo fooN |tr -d '\012'|tr N '\012' conftest.data
+[echo fooNbarN | tr -d '\012' | tr N '\012' conftest.data
AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include stdio.h
#include stdlib.h
#include string.h
int main ()
-{ /* Based on a test program from Karl Heuer. */
- char *line = NULL;
- size_t siz = 0;
- int len;
+{
FILE *in = fopen (./conftest.data, r);
if (!in)
return 1;
- len = getline (line, siz, in);
- exit ((len == 4 line strcmp (line, foo\n) == 0) ? 0 : 1);
+ {
+/* Test result for a NULL buffer and a zero size.
+ Based on a test program from Karl Heuer. */
+char *line = NULL;
+size_t siz = 0;
+int len = getline (line, siz, in);
+if (!(len == 4 line strcmp (line, foo\n) == 0))
+ return 1;
+ }
+ {
+/* Test result for a NULL buffer and a non-zero size.
+ This crashes on FreeBSD 8.0. */
+char *line = NULL;
+size_t siz = (size_t)(~0) / 4;
+if (getline (line, siz, in) == -1)
+ return 1;
+ }
+ return 0;
}
]])], [am_cv_func_working_getline=yes] dnl The library version works.
, [am_cv_func_working_getline=no] dnl The library version does NOT work.
--- tests/test-getline.c.orig Sun Jan 31 17:20:48 2010
+++ tests/test-getline.cSun Jan 31 17:20:22 2010
@@ -33,13 +33,13 @@
main (void)
{
FILE *f;
- char *line = NULL;
- size_t len = 0;
+ char *line;
+ size_t len;
ssize_t result;
/* Create test file. */
f = fopen (test-getline.txt, wb);
- if (!f || fwrite (a\nbc\nd\0f, 1, 8, f) != 8 || fclose (f) != 0)
+ if (!f || fwrite (a\nA\nbc\nd\0f, 1, 10, f) != 10 || fclose (f) != 0)
{
fputs (Failed to create sample file.\n, stderr);
remove (test-getline.txt);
@@ -54,13 +54,24 @@
}
/* Test initial allocation, which must include trailing NUL. */
+ line = NULL;
+ len = 0;
result = getline (line, len, f);
ASSERT (result == 2);
ASSERT (strcmp (line, a\n) == 0);
ASSERT (2 len);
+ free (line);
- /* Test growth of buffer, must not leak. */
+ /* Test initial allocation again, with line = NULL and len != 0. */
+ line = NULL;
+ len = (size_t)(~0) / 4;
+ result = getline (line, len, f);
+ ASSERT (result == 2);
+ ASSERT (strcmp (line, A\n) == 0);
+ ASSERT (2 len);
free (line);
+
+ /* Test growth of buffer, must not leak. */
line = malloc (1);
len = 0;
result = getline (line, len, f);
Re: [Bug-tar] getline() differences FreeBSD / GNU libc
2010-01-31 Bruno Haible br...@clisp.org
Work around getline() bug on FreeBSD 8.0.
* m4/getline.m4 (gl_FUNC_GETLINE): Also test result for a NULL buffer
and a non-zero size.
* tests/test-getline.c (main): Likewise.
* doc/posix-functions/getline.texi: Mention the FreeBSD bug.
Reported by Dennis noord...@cs.helsinki.fi via Eric Blake.
And similarly for getdelim.
2010-01-31 Bruno Haible br...@clisp.org
Work around getdelim() bug on FreeBSD 8.0.
* m4/getdelim.m4 (gl_FUNC_GETDELIM): Test whether getdelim supports an
initially NULL line. Set REPLACE_GETDELIM if getdelim exists but does
not work.
* lib/stdio.in.h (getdelim): Define as an alias if REPLACE_GETDELIM
is 1.
* m4/stdio_h.m4 (gl_STDIO_H_DEFAULTS): Initialize REPLACE_GETDELIM.
* modules/stdio (Makefile.am): Also substitute REPLACE_GETDELIM.
* tests/test-getdelim.c (main): Also test result for a NULL buffer and
a non-zero size.
* doc/posix-functions/getdelim.texi: Mention the FreeBSD bug.
--- doc/posix-functions/getdelim.texi.orig Sun Jan 31 17:33:06 2010
+++ doc/posix-functions/getdelim.texi Sun Jan 31 17:30:59 2010
@@ -14,6 +14,10 @@
@item
This function is missing a declaration on some platforms:
BeOS.
+...@item
+This function crashes when passed a pointer to a NULL buffer together with a
+pointer to a non-zero buffer size on some platforms:
+FreeBSD 8.0.
@end itemize
Portability problems not fixed by Gnulib:
--- lib/stdio.in.h.orig Sun Jan 31 17:33:06 2010
+++ lib/stdio.in.h Sun Jan 31 17:30:59 2010
@@ -340,7 +340,11 @@
#endif
#if @GNULIB_GETDELIM@
-# if !...@have_decl_getdelim@
+# if @REPLACE_GETDELIM@
+# undef getdelim
+# define getdelim rpl_getdelim
+# endif
+# if !...@have_decl_getdelim@ || @REPLACE_GETDELIM@
/* Read input, up to (and including) the next occurrence of DELIMITER, from
STREAM, store it in *LINEPTR (and NUL-terminate it).
*LINEPTR is a pointer returned from malloc (or NULL), pointing to *LINESIZE
--- m4/getdelim.m4.orig Sun Jan 31 17:33:06 2010
+++ m4/getdelim.m4 Sun Jan 31 17:30:59 2010
@@ -1,6 +1,6 @@
-# getdelim.m4 serial 5
+# getdelim.m4 serial 6
-dnl Copyright (C) 2005, 2006, 2007, 2009, 2010 Free Software Foundation, Inc.
+dnl Copyright (C) 2005-2007, 2009-2010 Free Software Foundation, Inc.
dnl
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -15,16 +15,71 @@
dnl Persuade glibc stdio.h to declare getdelim().
AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
- AC_REPLACE_FUNCS([getdelim])
AC_CHECK_DECLS_ONCE([getdelim])
- if test $ac_cv_func_getdelim = no; then
-gl_PREREQ_GETDELIM
+ AC_CHECK_FUNCS_ONCE([getdelim])
+ if test $ac_cv_func_getdelim = yes; then
+dnl Found it in some library. Verify that it works.
+AC_CACHE_CHECK([for working getdelim function],
[gl_cv_func_working_getdelim],
+[echo fooNbarN | tr -d '\012' | tr N '\012' conftest.data
+AC_RUN_IFELSE([AC_LANG_SOURCE([[
+#include stdio.h
+#include stdlib.h
+#include string.h
+int main ()
+{
+ FILE *in = fopen (./conftest.data, r);
+ if (!in)
+return 1;
+ {
+/* Test result for a NULL buffer and a zero size.
+ Based on a test program from Karl Heuer. */
+char *line = NULL;
+size_t siz = 0;
+int len = getdelim (line, siz, '\n', in);
+if (!(len == 4 line strcmp (line, foo\n) == 0))
+ return 1;
+ }
+ {
+/* Test result for a NULL buffer and a non-zero size.
+ This crashes on FreeBSD 8.0. */
+char *line = NULL;
+size_t siz = (size_t)(~0) / 4;
+if (getdelim (line, siz, '\n', in) == -1)
+ return 1;
+ }
+ return 0;
+}
+]])], [gl_cv_func_working_getdelim=yes] dnl The library version works.
+, [gl_cv_func_working_getdelim=no] dnl The library version does NOT work.
+, dnl We're cross compiling. Assume it works on glibc2 systems.
+ [AC_EGREP_CPP([Lucky GNU user],
+ [
+#include features.h
+#ifdef __GNU_LIBRARY__
+ #if (__GLIBC__ = 2)
+ Lucky GNU user
+ #endif
+#endif
+ ],
+ [gl_cv_func_working_getdelim=yes],
+ [gl_cv_func_working_getdelim=no])]
+)])
+ else
+gl_cv_func_working_getdelim=no
fi
if test $ac_cv_have_decl_getdelim = no; then
HAVE_DECL_GETDELIM=0
fi
+
+ if test $gl_cv_func_working_getdelim = no; then
+if test $ac_cv_func_getdelim = yes; then
+ REPLACE_GETDELIM=1
+fi
+AC_LIBOBJ([getdelim])
+gl_PREREQ_GETDELIM
+ fi
])
# Prerequisites of lib/getdelim.c.
--- m4/stdio_h.m4.orig Sun Jan 31 17:33:06 2010
+++ m4/stdio_h.m4 Sun Jan 31 17:30:59 2010
@@ -1,4 +1,4 @@
-# stdio_h.m4 serial 24
+# stdio_h.m4 serial 25
dnl Copyright (C) 2007-2010 Free Software Foundation, Inc.
dnl This file is free software; the Free
Re: maintainer-makefile troubles and suggestions
Hi Martin, sc_po_check: This one complains about files like lib/getopt.c not being listed as requiring translations. OK, it has a point there. Still, of the three possible solutions which come to my mind, none feels exactly right: 1. Add files, and require every translator of every module using gnulib to re-include the same old translations, or even worse, think of similar but different translations every time. It would be nice if the list of files to be added in this way could be maintained by gnulib. 2. Drop all localizing constructs from getopt.c and accept that messages won't be localized unless the system has a properly localized gnu-compatible getopt library installed. Same for other, similar replacement files, e.g. regcomp.c. 3. Have gnulib use a different domain, have the proper message files imported along with the rest of gnulib into the project source tree at pre-configure time, and have those files compiled and installed at make time if any of the replacement files requiring them is actually used. Yes, the current state is suboptimal. Most packages that use gnulib include files like lib/getopt.c in their list of files for POTFILES, i.e. they use approach 1. Approach 2 is strongly discouraged. There is the possibility to use approach 3, by - using the gnulib-tool options --po-base and --po-domain, - defining the DEFAULT_TEXT_DOMAIN macro in lib/Makefile.am. The PO files for gnulib will be automatically downloaded from the Translation Project's website http://translationproject.org/domain/gnulib.html. This approach should certainly be better documented and more used. Bruno
Re: new common math function modules
Paolo Bonzini wrote: I'll think I'll merge the test for EXP_LIBM, LOG_LIBM etc. into a single one - to save configure script execution time, as you say -. That's fair enough, thanks. Implemented as follows: 2010-01-31 Bruno Haible br...@clisp.org Perform the same test for many math.h functions. * m4/mathfunc.m4 (gl_COMMON_DOUBLE_MATHFUNC, gl_COMMON_DOUBLE_MATHFUNC_TEST): New macros. * m4/sqrt.m4 (gl_FUNC_SQRT): Invoke gl_COMMON_DOUBLE_MATHFUNC instead of gl_MATHFUNC. * modules/acos (configure.ac): Likewise. * modules/asin (configure.ac): Likewise. * modules/atan (configure.ac): Likewise. * modules/atan2 (configure.ac): Likewise. * modules/cbrt (configure.ac): Likewise. * modules/copysign (configure.ac): Likewise. * modules/cos (configure.ac): Likewise. * modules/cosh (configure.ac): Likewise. * modules/erf (configure.ac): Likewise. * modules/erfc (configure.ac): Likewise. * modules/exp (configure.ac): Likewise. * modules/fmod (configure.ac): Likewise. * modules/hypot (configure.ac): Likewise. * modules/j0 (configure.ac): Likewise. * modules/j1 (configure.ac): Likewise. * modules/jn (configure.ac): Likewise. * modules/lgamma (configure.ac): Likewise. * modules/log (configure.ac): Likewise. * modules/log10 (configure.ac): Likewise. * modules/log1p (configure.ac): Likewise. * modules/pow (configure.ac): Likewise. * modules/remainder (configure.ac): Likewise. * modules/sin (configure.ac): Likewise. * modules/sinh (configure.ac): Likewise. * modules/tan (configure.ac): Likewise. * modules/tanh (configure.ac): Likewise. * modules/y0 (configure.ac): Likewise. * modules/y1 (configure.ac): Likewise. * modules/yn (configure.ac): Likewise. Suggested by Paolo Bonzini. --- m4/mathfunc.m4.orig Sun Jan 31 19:32:47 2010 +++ m4/mathfunc.m4 Sun Jan 31 19:28:12 2010 @@ -1,4 +1,4 @@ -# mathfunc.m4 serial 2 +# mathfunc.m4 serial 3 dnl Copyright (C) 2010 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -58,3 +58,58 @@ m4_popdef([FUNC]) m4_popdef([func]) ]) + +# gl_COMMON_DOUBLE_MATHFUNC(FUNC) +# --- +# tests whether the function FUNC is available in libc or libm. +# It sets FUNC_LIBM to empty or -lm accordingly. +# FUNC must be one of the following functions, that are present on all systems +# and provided by libm on all systems except MacOS X, BeOS, Haiku: +# acos asin atan atan2 cbrt copysign cos cosh erf erfc exp fmod hypot j0 j1 +# jn lgamma log log10 log1p pow remainder sin sinh sqrt tan tanh y0 y1 yn + +AC_DEFUN([gl_COMMON_DOUBLE_MATHFUNC], +[ + AC_REQUIRE([gl_COMMON_DOUBLE_MATHFUNC_TEST]) + m4_pushdef([FUNC], [translit([$1],[abcdefghijklmnopqrstuvwxyz], +[ABCDEFGHIJKLMNOPQRSTUVWXYZ])]) + FUNC[]_LIBM=$POW_LIBM + AC_SUBST(FUNC[_LIBM]) + m4_popdef([FUNC]) +]) + +AC_DEFUN([gl_COMMON_DOUBLE_MATHFUNC_TEST], +[ + dnl We could use any of the following: + dnl gl_MATHFUNC([acos], [double], [(double)]) + dnl gl_MATHFUNC([asin], [double], [(double)]) + dnl gl_MATHFUNC([atan], [double], [(double)]) + dnl gl_MATHFUNC([atan2], [double], [(double, double)]) + dnl gl_MATHFUNC([cbrt], [double], [(double)]) + dnl gl_MATHFUNC([copysign], [double], [(double, double)]) + dnl gl_MATHFUNC([cos], [double], [(double)]) + dnl gl_MATHFUNC([cosh], [double], [(double)]) + dnl gl_MATHFUNC([erf], [double], [(double)]) + dnl gl_MATHFUNC([erfc], [double], [(double)]) + dnl gl_MATHFUNC([exp], [double], [(double)]) + dnl gl_MATHFUNC([fmod], [double], [(double, double)]) + dnl gl_MATHFUNC([hypot], [double], [(double, double)]) + dnl gl_MATHFUNC([j0], [double], [(double)]) + dnl gl_MATHFUNC([j1], [double], [(double)]) + dnl gl_MATHFUNC([jn], [double], [(int, double)]) + dnl gl_MATHFUNC([lgamma], [double], [(double)]) + dnl gl_MATHFUNC([log], [double], [(double)]) + dnl gl_MATHFUNC([log10], [double], [(double)]) + dnl gl_MATHFUNC([log1p], [double], [(double)]) + dnl gl_MATHFUNC([pow], [double], [(double, double)]) + dnl gl_MATHFUNC([remainder], [double], [(double, double)]) + dnl gl_MATHFUNC([sin], [double], [(double)]) + dnl gl_MATHFUNC([sinh], [double], [(double)]) + dnl gl_MATHFUNC([sqrt], [double], [(double)]) + dnl gl_MATHFUNC([tan], [double], [(double)]) + dnl gl_MATHFUNC([tanh], [double], [(double)]) + dnl gl_MATHFUNC([y0], [double], [(double)]) + dnl gl_MATHFUNC([y1], [double], [(double)]) + dnl gl_MATHFUNC([yn], [double], [(int, double)]) + gl_MATHFUNC([pow], [double], [(double, double)]) +]) --- m4/sqrt.m4.orig Sun Jan 31 19:32:47 2010 +++ m4/sqrt.m4 Sun Jan 31 19:30:39 2010 @@ -1,4 +1,4 @@ -# sqrt.m4 serial 2 +# sqrt.m4 serial 3
