NetBSD Problem Report #33322

From www@netbsd.org  Thu Apr 20 21:49:23 2006
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
	id 51ED063B8C7; Thu, 20 Apr 2006 21:49:23 +0000 (UTC)
Message-Id: <20060420214923.51ED063B8C7@narn.netbsd.org>
Date: Thu, 20 Apr 2006 21:49:23 +0000 (UTC)
From: b1ff@fr33.b33r.net
Reply-To: b1ff@fr33.b33r.net
To: gnats-bugs@netbsd.org
Subject: textproc/dict-{client,server} gcc 3.4 alloca() problem
X-Send-Pr-Version: www-1.0

>Number:         33322
>Category:       pkg
>Synopsis:       textproc/dict-{client,server} gcc 3.4 alloca() problem
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 20 21:50:00 +0000 2006
>Last-Modified:  Fri Apr 21 07:50:01 +0000 2006
>Originator:     Mathieu
>Release:        3.0.0_STABLE
>Organization:
>Environment:
NetBSD sal.lan 3.0.0_STABLE NetBSD 3.0.0_STABLE (SPECIFIC) #0: Sat Apr  8 22:19:10 EDT 2006  mathieu@sal.lan:/usr/src/sys/arch/i386/compile/SPECIFIC i386
>Description:
cc -c -Ilibmaa -DHAVE_CONFIG_H -I/usr/pkg/include -I/usr/include -I/usr/pkg/gcc34/include -I. -O2 -march=pentium4 -pipe -I/usr/pkg/include -I/usr/include -I/usr/pkg/gcc34/include -DUSE_DICT_ORG -DUSE_PLUGIN -DDICT_PLUGIN_PATH=\"/usr/pkg/libexec/\" -DDICT_DICTIONARY_PATH=\"/usr/pkg/share/\" -DDICT_VERSION=\"1.9.15\" -DDICT_CONFIG_PATH=\"/usr/pkg/etc/\"  dict.c -o dict.o
In file included from dict.h:27,
                 from dict.c:24:
dictP.h:72: warning: conflicting types for built-in function 'alloca'
In file included from dictP.h:245,
                 from dict.h:27,
                 from dict.c:24:
/pkg/pkg/gcc34/bin/../lib/gcc/i386--netbsdelf3.0.0/3.4.6/include/stdlib.h:259: error: conflicting types for 'alloca'
dictP.h:72: error: previous declaration of 'alloca' was here
/pkg/pkg/gcc34/bin/../lib/gcc/i386--netbsdelf3.0.0/3.4.6/include/stdlib.h:259: error: conflicting types for 'alloca'
dictP.h:72: error: previous declaration of 'alloca' was here
gmake: *** [dict.o] Error 1
*** Error code 2

Similar error with libmaa/maaP.h.

>How-To-Repeat:
GCC_REQD=3.4

>Fix:
Replacement for patch-aa:

--- dictP.h.orig        2004-10-06 10:59:10.000000000 -0400
+++ dictP.h     2006-04-20 17:35:15.000000000 -0400
@@ -61,6 +61,7 @@
 # define HAVE_ALLOCA_H 1
 #endif

+#if !HAVE_ALLOCA
 #if HAVE_ALLOCA_H
 # include <alloca.h>
 #else
@@ -68,12 +69,13 @@
 # pragma alloca
 # else
 #  ifndef alloca /* predefined by HP cc +Olibcalls */
-#  if !defined(__svr4__) && !defined(__sgi__)  /* not on IRIX */
+#  if !defined(__svr4__) && !defined(__sgi__) && !defined(__DragonFly__) && !defined(__FreeBSD__)  /* not on IRIX */
     char *alloca ();
 #  endif
 #  endif
 # endif
 #endif
+#endif

 /* Get string functions */
 #if STDC_HEADERS

And patch-ab:

--- libmaa/maaP.h.orig  2003-10-26 08:03:24.000000000 -0500
+++ libmaa/maaP.h       2006-04-20 17:35:24.000000000 -0400
@@ -33,6 +33,7 @@
 #define __FUNCTION__ __FILE__
 #endif

+#if !HAVE_ALLOCA
 /* AIX requires this to be the first thing in the file.  */
 #if HAVE_ALLOCA_H
 # include <alloca.h>
@@ -41,10 +42,13 @@
 #  pragma alloca
 # else
 #  ifndef alloca /* predefined by HP cc +Olibcalls */
+#  if !defined(__DragonFly__) && !defined(__FreeBSD__)
     char *alloca ();
 #  endif
+#  endif
 # endif
 #endif
+#endif

 /* Get string functions */
 #if STDC_HEADERS

Makes it build here. Not sure if checking for HAVE_ALLOCA is the
correct way. But if it is, maybe the middle __whateverOS__ checks
aren't needed?

>Audit-Trail:
From: joerg@britannica.bec.de
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/33322: textproc/dict-{client,server} gcc 3.4 alloca() problem
Date: Fri, 21 Apr 2006 09:47:09 +0200

 On Thu, Apr 20, 2006 at 09:50:00PM +0000, b1ff@fr33.b33r.net wrote:
 > Makes it build here. Not sure if checking for HAVE_ALLOCA is the
 > correct way. But if it is, maybe the middle __whateverOS__ checks
 > aren't needed?

 The problem is that some platforms have alloca in libc or as compiler
 builtin, but don't provide it in system headers.

 I don't have the time to deal with this issue, but whoever wants to
 handle it, should go through all patches in the tree which handle this
 case already for DragonFly.

 Joerg

Home	PR Database Search