[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    problem with -pedantic-errors in KDE_CHECK_FUNC_EXT (acinclude.m4.in)
From:       Benjamin Reed <ranger () befunk ! com>
Date:       2003-02-21 19:42:32
[Download RAW message or body]

On MacOSX, I'm having some strange behavior in the checks for, eg, 
gethostname and such.  The m4 code has this in it in the 
KDE_CHECK_FUNC_EXT bit:

---(snip!)---
if test "$GXX" = "yes"; then
   CXXFLAGS="$CXXFLAGS -pedantic-errors"
fi
---(snip!)---

...this is causing the check to fail like so:

---(snip!)---
configure:33326: checking for gethostname
configure:33372: g++ -c -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall 
-pedantic -W -Wpointer-arith -Wmissing-prototypes -Ww
rite-strings -O2 -fno-exceptions -fno-check-new -pedantic-errors  
-DQT_THREAD_SUPPORT -no-cpp-precomp -fno-common -I/sw/include 
-I/sw/include conftest.cc >&5
conftest.cc:1:7: line number out of range
configure:33375: $? = 1
configure: failed program was:
#line 33349 "configure"
#include "confdefs.h"


#include <stdlib.h>
#include <unistd.h>


int
main ()
{


char buffer[200];
gethostname(buffer, 200);


   ;
   return 0;
}
configure:33402: result: no
---(snip!)---

It seems that what's actually happening is it's failing, but not 
because gethostname is not there, but because cpp doesn't like autoconf 
sticking a line number in the c file that doesn't actually exist.

If I turn the "-pedantic-errors" bit off and make it "-pedantic" (so it 
doesn't treat it like an error), the configure check passes.

Is this a bug in autoconf, my c preprocessor, the additional kde cflag, 
or some or all of the above?  I can only assume the -pedantic-errors 
bit was added for good reason, but I'm not sure where to look for 
answers on the "proper" way to fix this.

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]