Bug 80916 - db43 does not build (with gcc4.0?)
db43 does not build (with gcc4.0?)
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: FreeBSD ports mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-11 22:00 UTC by kutulu
Modified: 2005-08-01 18:40 UTC (History)
1 user (show)

See Also:


Attachments
file.diff (693 bytes, patch)
2005-05-11 22:00 UTC, kutulu
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description kutulu 2005-05-11 22:00:21 UTC
I have been running a machine with gcc40 as the system compiler and this is one of the ports that doesn't compile.  I don't appear to have this problem on systems using the base gcc as the system compiler.  The issue appears to be a change in storage type in a single function.

However, the patch I generated cannot run from the normal patch target in ports Makefiles, since the file that needs to be patched is actually generated during the config.  Hopefully someone better versed with the db43 port can do this properly.

How-To-Repeat: In /usr/ports/databases/db43: 

CC=/usr/local/bin/gcc40 make
Comment 1 vs freebsd_committer 2005-05-12 07:59:55 UTC
State Changed
From-To: open->feedback

Waiting for maintainer feedback
Comment 2 matthias.andree 2005-07-27 17:28:05 UTC
I've tried to reproduce this on FreeBSD 4.11-RELEASE-p11 with
gcc-4.0.0_20041226 (FreeBSD 4.11 package), but failed.

make USE_GCC=4.0

has apparently worked for me. Please try if "make USE_GCC=4.0" works for
you and follow up with what you've found.

-- 
Matthias Andree
Comment 3 matthias.andree 2005-07-28 22:26:51 UTC
Well, I was able to reproduce the problem on FreeBSD 5.4-mumble with gcc
4.0.2 as of July 2005, and the patch below works for me.

I don't think we should bump the PORTREVISION as this is a build-time
only problem - either people can compile this, then they don't need an
update of the port, or they cannot compile this, then they will be
rebuilding even without PORTREVISION bumped.

--- a/ports/databases/db43/Makefile	Sat May  7 20:26:05 2005
+++ b/ports/databases/db43/Makefile	Thu Jul 28 22:55:44 2005
@@ -48,6 +48,9 @@
 pre-configure:
 	${CHMOD} u+w ${WRKSRC}/../dist/configure
 
+post-configure:
+	@${REINPLACE_CMD} -e '/^extern  void db_rpc_serverprog/ d;' ${WRKSRC}/db_server.h
+
 post-install:
 .for i in libdb libdb_cxx
 	${LN} -s -f ${PORTNAME}/${i}-${BDBVER}.so.0 ${PREFIX}/lib

-- 
Matthias Andree
Comment 4 vs freebsd_committer 2005-07-29 08:37:06 UTC
Am 28. Jul 2005 um 23:26 CEST schrieb Matthias Andree:
> Well, I was able to reproduce the problem on FreeBSD 5.4-mumble with gcc
> 4.0.2 as of July 2005, and the patch below works for me.
>  
> +post-configure:
> +	@${REINPLACE_CMD} -e '/^extern  void db_rpc_serverprog/ d;' ${WRKSRC}/db_server.h
> +

Shouldn't this better be a patch? I hate digging through REINPLACE_CMDs
on updates only to find out that they're basically doing nothing on
future updates. Patches fail more noisily and point you to the problem.

Volker
-- 
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
It's a million to one chance, but it just might work.
Comment 5 matthias.andree 2005-07-29 09:27:03 UTC
On Fri, 29 Jul 2005, Volker Stolz wrote:

> > +post-configure:
> > +	@${REINPLACE_CMD} -e '/^extern  void db_rpc_serverprog/ d;' ${WRKSRC}/db_server.h
> > +
> 
> Shouldn't this better be a patch? I hate digging through REINPLACE_CMDs
> on updates only to find out that they're basically doing nothing on
> future updates. Patches fail more noisily and point you to the problem.

The requisite is that this runs in post-configure or pre-build, as the
files that need patching are generated as late as in do-configure, as
Michael already stated in his original report. rpcgen -C is used to
build - among others - db_server.h from ../rpc_server/db_server.x, and
is called from ./configure.

I have filed a support request with SleepyCat, in their first response,
they said they found a bug in GCC 4.0.0 or 4.0.1 that triggered when
building the Java API, which might also be affecting the RPC server.

It might also be a bug with "rpcgen" on FreeBSD, as the SUSE Linux 9.3
rpcgen does not create the conflicting db_server.h line, whereas its
documentation warns:

   "Name clashes can occur when using program definitions, since the appar-
    ent  scoping  does  not  really apply.  Most of these can be avoided by
    giving unique names for programs, versions, procedures and types."
   (Linux rpcgen(1) manual page)

If rpcgen generates an extern declaration for a static function, this
looks like an rpcgen bug to me. So perhaps this should spawn a problem
report for bin and one for ports/lang/gcc40 each.

Also, GCC 4.0.1+ is apparently overzealous by making the error shown
below an error, I see no requirement for this in "The C Programming
Language", appendix A, and no other compiler I have access to, flags an
error, even with "strict" settings. SleepyCat might have a point here.

If someone knows a reference that requires a compiler diagnostic aka
error, please follow up.

### db_server.h ###

extern  void db_rpc_serverprog_4003(struct svc_req *rqstp, register SVCXPRT *transp);

### db_server_svc.c ###

static void
db_rpc_serverprog_4003(struct svc_req *rqstp, register SVCXPRT *transp)
{
...

### GCC errors ###

db_server_svc.c:30: error: static declaration of 'db_rpc_serverprog_4003' follows non-static declaration
db_server.h:1013: error: previous declaration of 'db_rpc_serverprog_4003' was here

-- 
Matthias Andree
Comment 6 vs freebsd_committer 2005-07-29 11:45:10 UTC
State Changed
From-To: feedback->closed

Fixed, thanks!
Comment 7 kutulu 2005-08-01 18:32:22 UTC
I know this PR is closed but I wanted to make sure this got into the 
audit trail:

The bug here is actually an rpcgen bug from FreeBSD 5.x and up; the main 
RPC program function is always emitted 'static' but the header file 
declares all functions, including that one, as 'extern'.  This changed 
between 4.x and 5.x -- previously the 'extern' declaractor was not 
emitted at all.

I've submitted a bug report for rpcgen; I don't know if that means we 
can remove this patch once rpcgen is fixed, since it has been "broken" 
since early in 5.x.

--Mike