The gl_INLINE macro was failing to define HAVE_INLINE,
and that led to link errors when building coreutils with CFLAGS=-O.
gl_INLINE used cpp and $CPPFLAGS, and since the latter doesn't
include $CFLAGS, it missed the critical -O option.
Without -O, gcc *does* define __NO_INLINE__, so HAVE_INLINE was not
defined. However, when compiling (with $CFLAGS containing -O), there
was no external definition of any function like xnmalloc or xcharalloc.
Paul, here's the change I'm using:
2006-11-10 Jim Meyering <[EMAIL PROTECTED]>
* m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp,
so that relevant options in CFLAGS (like -O, -fno-inline) are
taken into account.
Index: m4/inline.m4
===================================================================
RCS file: /sources/gnulib/gnulib/m4/inline.m4,v
retrieving revision 1.2
diff -u -r1.2 inline.m4
--- m4/inline.m4 8 Nov 2006 14:03:04 -0000 1.2
+++ m4/inline.m4 10 Nov 2006 11:09:44 -0000
@@ -1,4 +1,4 @@
-# inline.m4 serial 2
+# inline.m4 serial 3
dnl Copyright (C) 2006 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -19,11 +19,13 @@
else
dnl GCC defines __NO_INLINE__ if not optimizing or if -fno-inline is
dnl specified.
- AC_EGREP_CPP([bummer], [
- #ifdef __NO_INLINE__
- bummer
- #endif
- ], [gl_cv_c_inline_effective=no], [gl_cv_c_inline_effective=yes])
+ AC_COMPILE_IFELSE(
+ [AC_LANG_PROGRAM([[]],
+ [EMAIL PROTECTED]:@ifdef __NO_INLINE__
+ @%:@error "inline is not effective"
+ @%:@endif]])],
+ [gl_cv_c_inline_effective=yes],
+ [gl_cv_c_inline_effective=no])
fi
])
if test $gl_cv_c_inline_effective = yes; then
