On Tue, Nov 18, 2008 at 5:38 PM, Neels J. Hofmeyr <neels_at_elego.de> wrote:
> Hi Greg,
>
> r34258 breaks my --maintainer-mode build of trunk (ubuntu 8.10 i686) with
> the following error:
Eek. Sorry about that.
Okay. Seems like I'll need to add some extra work to detect versions
of GCC and add different flags based on that. I'll scrounge around the
autoconf pages to see if there is an easy mechanism for that.
>...
\> 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?
Nope. Others will run into the same problem. Certainly, we could be a
bit stricter about "maintainer mode" and the minimum requirements for
that, but I don't think "min GCC version" is something to legislate.
That's not one of the things to ask people to wantonly upgrade.
Thus... we figure out some other way to work with that gcc version.
> 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
> `apr__SHA512_End'
> subversion/tests/libsvn_subr/auth-test:/arch/elego/svn/apr-1.2.12/random/unix/sha2.c:895:
> 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'
> subversion/tests/libsvn_subr/auth-test:/arch/elego/svn/apr-1.2.12/locks/unix/proc_mutex.c:847:
> 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
> `apr_dso_error'
> subversion/tests/libsvn_subr/auth-test:/arch/elego/svn/apr-1.2.12/dso/unix/dso.c:243:
> first defined here
> subversion/tests/libsvn_test-1.la: file not recognized: File format not
> recognized
> collect2: ld returned 1 exit status
> make: *** [test] Error 1
> ]]]
That sounds like some kind of clean error you were wrestling with. I
don't understand how flag changes would do such a thing.
> 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.
Yah. That's bad. I'd need to see more info / failure messages / etc
before I could figure out what is wrong. That said, since you're going
to re-run autoconf to alter the flags coming out of configure.ac, then
you really should have run extra-clean.
> 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?
Nope. They're warnings. Moving the warnings to be generated on a
branch doesn't change the fact that they exist on the trunk. Putting
the extra warnings on the branch is simply "papering over" what is
really happening on trunk.
> Hope you're not mad, Greg, but after thinking a lot, I decided to revert the
> change for now (reverted in r34263).
Certainly not!! It broke the build, and that is the easy way to fix it
again. ("worked for me", but it isn't as easy as that, hm? :-)
> I feel that we're not ready for it yet,
> especially in this phase of development. Maybe there are other people out
What phase is that? The phase where we get to hide warnings to reach
some kind of pretend-clean build? Where no warnings are issued simply
because we didn't turn on flags? Where the warnings are present, but
because we put on our blinders that we can ignore them?
:-) ... I respectfully disagree. This is just as fine as a time as
any. I made no change to the code. Nothing was destabilized. It is
simply that GCC will give us more info about where our code may have
problems, or could be clearer.
> there using yet older compilers who want to remove even more -W flags? And I
This is my concern, but (honestly) I think the easiest is to put in
the changes and wait for feedback. The set of people using
--enable-maintainer-mode is small, and (theoretically) well-versed
enough to give us proper feedback. Shoot. They should be on this list
interacting with us already.
> 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
> matters...
Unless you use -Werror, then various warnings should not be a problem.
Personally, I think that cleaning up warnings is one of those
"bite-sized tasks" that new developers could help with. Or things to
do when you're tired of slogging through update_editor.c, and need
something brainless.
I thought we had all these extensive errors, and when I started
developing again, missed them. But I traced the flags all the way back
to CVS, and couldn't find anything. I suspect that older GCCs gave
more warnings than today's, so we need to force gcc into being
noisier. I was appalled when I found that I could call a function
without a prototype -- gcc was "supposed" to tell me. But no...
missing flags. Thus, I put a bunch back in. We can make all kinds of
mistakes, and the current flagset doesn't tell us. I think these flags
are important for all (gcc-based) developers to have and to respond
to.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-19 07:19:34 CET