[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Trunk build broken: Re: svn commit: r34258 - trunk

From: Neels J. Hofmeyr <neels_at_elego.de>
Date: Wed, 19 Nov 2008 02:38:44 +0100

Hi Greg,

r34258 breaks my --maintainer-mode build of trunk (ubuntu 8.10 i686) with
the following error:

checking zlib.h usability... no
checking zlib.h presence... yes
configure: WARNING: zlib.h: present but cannot be compiled
configure: WARNING: zlib.h: check for missing prerequisite headers?
configure: WARNING: zlib.h: see the Autoconf documentation
configure: WARNING: zlib.h: section "Present But Cannot Be Compiled"
configure: WARNING: zlib.h: proceeding with the preprocessor's result
configure: WARNING: zlib.h: in the future, the compiler will take precedence
configure: WARNING: ## -------------------------------------------- ##
configure: WARNING: ## Report this to http://subversion.tigris.org/ ##
configure: WARNING: ## -------------------------------------------- ##
checking for zlib.h... yes
checking for inflate in -lz... no
configure: error: subversion requires zlib

I can't find any problem with my zlib installation. The "dev" package of it
is installed and I can manually compile a tiny test program with it.

I finally succeeded to mess with my ./configure script so that it shows the
actual compiler error message:

++ gcc -c -g -g -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -pthread -D_LARGEFILE64_SOURCE -DNE_LFS
-Wpointer-arith -Wwrite-strings -Wshadow -ansi -std=c99 -Wextra-tokens
-Wnewline-eof -Wall -Wformat=2 -Wunused -Wshorten-64-to-32
-Waggregate-return -Wstrict-prototypes -Wold-style-definition
-Wmissing-prototypes -Wmissing-declarations -Wno-multichar -Wredundant-decls
-Wnested-externs -Wunreachable-code -Winline -Wno-long-long -DSVN_DEBUG
cc1: error: unrecognized command line option "-Wextra-tokens"
cc1: error: unrecognized command line option "-Wnewline-eof"
cc1: error: unrecognized command line option "-Wshorten-64-to-32"

Hm, should I upgrade my GCC?
Anyway, when I remove those three -W arguments, my build issues what must be
thousands of compiler warnings, and finally fails with:

subversion/tests/libsvn_subr/hashdump-test: In function `apr__SHA512_End':
/arch/elego/svn/apr-1.2.12/random/unix/sha2.c:895: multiple definition of
first defined here
subversion/tests/libsvn_subr/hashdump-test: In function `apr_os_proc_mutex_put':
/arch/elego/svn/apr-1.2.12/locks/unix/proc_mutex.c:847: multiple definition
of `apr_os_proc_mutex_put'
first defined here
subversion/tests/libsvn_subr/hashdump-test: In function `apr_dso_error':
/arch/elego/svn/apr-1.2.12/dso/unix/dso.c:243: multiple definition of
first defined here
subversion/tests/libsvn_test-1.la: file not recognized: File format not
collect2: ld returned 1 exit status
make: *** [test] Error 1

When trying to revert r34258, I noticed I had to do an all clean trunk
checkout to make this error go away. `make dist-clean' wasn't enough! So I
think there might be a bug or missing feature in the build scripts that
doesn't remove some libraries upon make clean, huge question mark? Got no
idea really.

After that, I tried again to only revert those three -W flags that caused an
error in the first place. I did that in another all clean checkout of trunk,
to be really sure.

And *that* worked out. But now the --maintainer-mode build issues 43 new
warnings. And that's a good thing, in principle. Shouldn't we first add all
the -W flags on a branch and minimize the amount of new warnings showing up?

Hope you're not mad, Greg, but after thinking a lot, I decided to revert the
change for now (reverted in r34263). I feel that we're not ready for it yet,
especially in this phase of development. Maybe there are other people out
there using yet older compilers who want to remove even more -W flags? And I
obviously don't want to give up the --maintainer-mode build. The mass of
warnings is good, in a way, but I don't think all of us should be forced to
read all of them all the time, even when working on entirely different

But an emphatic +1 for the compiler to issue as many warnings as possible.
I'm for a branch to introduce these, e.g. asking people to try the build of
the branch, removing the bulk of new warnings gradually. Sounds good?


gstein_at_tigris.org wrote:
> Author: gstein
> Date: Tue Nov 18 15:04:41 2008
> New Revision: 34258
> Log:
> For maintainers, add a bunch of flags to the GCC compilation line to flag
> more warnings about our constructs.
> * configure.ac:
> (CFLAGS): add flags when --enable-maintainer-mode is specified
> Modified:
> trunk/configure.ac
> Modified: trunk/configure.ac
> URL: http://svn.collab.net/viewvc/svn/trunk/configure.ac?pathrev=34258&r1=34257&r2=34258
> ==============================================================================
> --- trunk/configure.ac Tue Nov 18 14:38:36 2008 (r34257)
> +++ trunk/configure.ac Tue Nov 18 15:04:41 2008 (r34258)
> @@ -713,8 +713,14 @@ AS_HELP_STRING([--enable-maintainer-mode
> fi
> enable_debugging=yes
> if test "$GCC" = "yes"; then
> - CFLAGS="$CFLAGS -Wpointer-arith -Wwrite-strings -Wshadow"
> + CFLAGS="$CFLAGS -Wpointer-arith -Wwrite-strings -Wshadow -ansi -std=c99 -Wextra-tokens -Wnewline-eof -Wall -Wformat=2 -Wunused -Wshorten-64-to-32 -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wno-multichar -Wredundant-decls -Wnested-externs -Wunreachable-code -Winline -Wno-long-long"
> CXXFLAGS="$CXXFLAGS -Wpointer-arith -Wwrite-strings -Wshadow"
> +
> + dnl some additional flags that can be handy for an occasional review,
> + dnl but throw too many warnings in svn code, of too little importance,
> + dnl to keep these enabled. Remove the "dnl" to do a run with these
> + dnl switches enabled.
> + dnl CFLAGS="$CFLAGS -Wswitch-enum -Wswitch-default"
> fi
> fi
> ])
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: svn-help_at_subversion.tigris.org

Received on 2008-11-19 02:39:17 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.