Simon Josefsson wrote:
> > This is the same issue as with fchownat before, and this patch makes
> > the compile and run successful:
>
> Is the patch the right thing?
No, the proposed patch is not optimal: On platforms where the function simply
does not exist (such as MacOS X or Solaris), it causes gnulib's replacement to
be called 'rpl_strnlen'. Which is confusing when people debug. The idioms
set out in build-aux/c++defs.h suggest to call the function 'strnlen' then.
This fixes it:
2010-04-25 Bruno Haible <br...@clisp.org>
strnlen: Fix a C++ test error on MacOS X and Solaris.
* m4/strnlen.m4 (gl_FUNC_STRNLEN): Don't set REPLACE_STRNLEN to 1 if
the function is not declared.
Reported by Jarno Rajahalme <jarno.rajaha...@nsn.com> and
Simon Josefsson.
--- m4/strnlen.m4.orig Sun Apr 25 12:23:15 2010
+++ m4/strnlen.m4 Sun Apr 25 12:19:18 2010
@@ -1,4 +1,4 @@
-# strnlen.m4 serial 11
+# strnlen.m4 serial 12
dnl Copyright (C) 2002-2003, 2005-2007, 2009-2010 Free Software Foundation,
dnl Inc.
dnl This file is free software; the Free Software Foundation
@@ -15,15 +15,15 @@
AC_CHECK_DECLS_ONCE([strnlen])
if test $ac_cv_have_decl_strnlen = no; then
HAVE_DECL_STRNLEN=0
+ else
+ AC_FUNC_STRNLEN
+ dnl Note: AC_FUNC_STRNLEN does AC_LIBOBJ([strnlen]).
+ if test $ac_cv_func_strnlen_working = no; then
+ REPLACE_STRNLEN=1
+ fi
fi
-
- AC_FUNC_STRNLEN
- if test $ac_cv_func_strnlen_working = no; then
- REPLACE_STRNLEN=1
- # This is necessary because automake-1.6.1 doesn't understand
- # that the above use of AC_FUNC_STRNLEN means we may have to use
- # lib/strnlen.c.
- #AC_LIBOBJ([strnlen])
+ if test $HAVE_DECL_STRNLEN = 0 || test $REPLACE_STRNLEN = 1; then
+ AC_LIBOBJ([strnlen])
gl_PREREQ_STRNLEN
fi
])
