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
State Changed From-To: open->feedback Waiting for maintainer feedback
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
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
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.
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
State Changed From-To: feedback->closed Fixed, thanks!
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