[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

inline.m4: use compiler, not cpp

From: Jim Meyering
Subject: inline.m4: use compiler, not cpp
Date: Fri, 10 Nov 2006 12:14:53 +0100

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  <address@hidden>

        * 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 @@
        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_LANG_PROGRAM([[]],
+          address@hidden:@ifdef __NO_INLINE__
+              @%:@error "inline is not effective"
+            @%:@endif]])],
+        [gl_cv_c_inline_effective=yes],
+        [gl_cv_c_inline_effective=no])
   if test $gl_cv_c_inline_effective = yes; then

reply via email to

[Prev in Thread] Current Thread [Next in Thread]