You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Neels J. Hofmeyr" <ne...@elego.de> on 2008/11/19 01:38:44 UTC
Trunk build broken: Re: svn commit: r34258 - trunk
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
-DAP_DEBUG -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE conftest.c
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
`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
]]]
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
matters...
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?
~Neels
gstein@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@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org
>
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Stein wrote:
> The flags are on again, in r34280. [...]
> - CFLAGS="$CFLAGS -Wpointer-arith -Wwrite-strings -Wshadow"
> + AC_MSG_NOTICE([maintainer-mode: adding GCC warning flags])
> + CFLAGS="$CFLAGS -Wpointer-arith -Wwrite-strings -Wshadow
> -ansi -std=c99 -Wall -Wformat=2 -Wunused -Waggregate-return
> -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes
> -Wmissing-declarations -Wno-multichar -Wredundant-decls
> -Wnested-externs -Wunreachable-code -Winline -Wno-long-long"
Note that "-ansi" means "-std=c89" which is contradicted by "-std=c99".
We should use just "-ansi".
I also recommend:
-Wdeclaration-after-statement (we make this mistake fairly often)
-Wundef
and I also use:
-Wcast-qual (results in several warnings, some incurable)
-Wno-system-headers (don't warn about things in system headers [1])
[1] This is the default in GCC 4.1.2, but I think I started using it
with a version of GCC in which it was not the default.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Nov 18, 2008 at 22:38, Neels J. Hofmeyr <ne...@elego.de> wrote:
>...
> +1 for a concerted effort to remove the warnings that were previously
> omitted, and to change the --maintainer-mode build on trunk afterwards, as
> soon as possible.
The flags are on again, in r34280. Hyrum's been knocking out some of
the warnings. Looks like we're at 55 warnings right now (see
attached).
> Greg, could you post a clean `make | grep "^[^[:blank:]]\+: "' using all of
> the -Wflags that work on your GCC? In case I don't get all of the warnings
> with mine.
See attached.
Cheers,
-g
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Greg Stein wrote:
>> 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.
You mean `extraclean'. I didn't know that, thanks! I'll use extraclean from
now on.
>
>> 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?
Yeah, I was expecting that :)
> :-) ... 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.
But I need to see any new warnings I am introducing while I'm fixing totally
unrelated stuff. If I see other warnings all over, it makes that part very
difficult.
Ok, maybe instead of a branch we should post a transcript of the new
warnings so that people scan it when they choose, not on every compile.
> 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.
lol, I know what you mean :)
> 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.
+1 for a concerted effort to remove the warnings that were previously
omitted, and to change the --maintainer-mode build on trunk afterwards, as
soon as possible.
Greg, could you post a clean `make | grep "^[^[:blank:]]\+: "' using all of
the -Wflags that work on your GCC? In case I don't get all of the warnings
with mine.
Thanks
~Neels
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Jens Seidel <je...@users.sf.net>.
On Thu, Nov 20, 2008 at 12:26:15AM -0800, Greg Stein wrote:
> On Thu, Nov 20, 2008 at 00:04, Jens Seidel <je...@users.sf.net> wrote:
> > I think you did it wrong.
> >
> > CFLAGS="$CFLAGS_KEEP -Wextra-tokens"
> > AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP="$CFLAGS"])
> >
> > If this test fails CFLAGS_KEEP="$CFLAGS" is executed which sets
> > CFLAGS_KEEP to the current value of $CFLAGS which contains -Wextra-tokens.
> >
> > This cannot be right, true?
>
> It is right. If the compilation is successful, then I want to keep the
> flag that I just tested.
Ah, right. You put code in the success-clause of AC_COMPILE_IFELSE.
> > PS: Don't know why I use "([[]])" (probably I just copied it wrong other
s/wrong/from/
> > source). Shouldn't "()" or "([])" be sufficient ([,] are quote characters)?
>
> I've stopped trying to optimize or be precise with my use of quote
> characters in m4. It's just all fucked up, and not worth the cycles.
OK, I hoped you know autoconf better that I so that I can simplify my own
macros ...
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Nov 20, 2008 at 00:04, Jens Seidel <je...@users.sf.net> wrote:
>...
> I think you did it wrong.
>
> CFLAGS_KEEP="$CFLAGS"
> AC_LANG_PUSH([C])
>
> CFLAGS="$CFLAGS_KEEP -Wextra-tokens"
> AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP="$CFLAGS"])
>
> If this test fails CFLAGS_KEEP="$CFLAGS" is executed which sets
> CFLAGS_KEEP to the current value of $CFLAGS which contains -Wextra-tokens.
>
> This cannot be right, true?
It is right. If the compilation is successful, then I want to keep the
flag that I just tested.
> PS: Don't know why I use "([[]])" (probably I just copied it wrong other
> source). Shouldn't "()" or "([])" be sufficient ([,] are quote characters)?
I've stopped trying to optimize or be precise with my use of quote
characters in m4. It's just all fucked up, and not worth the cycles.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Jens Seidel <je...@users.sf.net>.
Hi Greg,
On Wed, Nov 19, 2008 at 11:28:18PM -0800, Greg Stein wrote:
> Thanks, Jens, this helped me come up with a short pattern for flag
> availability detection, which I've now committed in r34280.
(Because of your top posting I removed my sample code, your fault :-()
I think you did it wrong.
CFLAGS_KEEP="$CFLAGS"
AC_LANG_PUSH([C])
CFLAGS="$CFLAGS_KEEP -Wextra-tokens"
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])], [CFLAGS_KEEP="$CFLAGS"])
If this test fails CFLAGS_KEEP="$CFLAGS" is executed which sets
CFLAGS_KEEP to the current value of $CFLAGS which contains -Wextra-tokens.
This cannot be right, true?
PS: Don't know why I use "([[]])" (probably I just copied it wrong other
source). Shouldn't "()" or "([])" be sufficient ([,] are quote characters)?
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Greg Stein <gs...@gmail.com>.
Thanks, Jens, this helped me come up with a short pattern for flag
availability detection, which I've now committed in r34280.
On Wed, Nov 19, 2008 at 05:27, Jens Seidel <je...@users.sf.net> wrote:
> On Tue, Nov 18, 2008 at 10:19:11PM -0800, Greg Stein wrote:
>> 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.
>
> I had this problem in the past too and tried to parse g++ --version. This
> failed on various distributions because of vendor strings (e.g. Debian)
> in the output.
>
> I solved it by using:
> if test x$GXX = xyes; then
> AC_LANG_PUSH(C++)
> # Use -Wextra or the older -W ?
> CXXFLAGSold="$CXXFLAGS"
> CXXFLAGS="-Wextra $CXXFLAGS"
> AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])],,
> [CXXFLAGS="-W $CXXFLAGSold"
> AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])],,CXXFLAGS="$CXXFLAGSold")])
> fi
>
> So I just tested whether an empty file can be compiled and changed the compiler
> flags if not.
>
> Jens
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Jens Seidel <je...@users.sf.net>.
On Tue, Nov 18, 2008 at 10:19:11PM -0800, Greg Stein wrote:
> 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.
I had this problem in the past too and tried to parse g++ --version. This
failed on various distributions because of vendor strings (e.g. Debian)
in the output.
I solved it by using:
if test x$GXX = xyes; then
AC_LANG_PUSH(C++)
# Use -Wextra or the older -W ?
CXXFLAGSold="$CXXFLAGS"
CXXFLAGS="-Wextra $CXXFLAGS"
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])],,
[CXXFLAGS="-W $CXXFLAGSold"
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])],,CXXFLAGS="$CXXFLAGSold")])
fi
So I just tested whether an empty file can be compiled and changed the compiler
flags if not.
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Nov 18, 2008 at 5:38 PM, Neels J. Hofmeyr <ne...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Trunk build broken: Re: svn commit: r34258 - trunk
Posted by Neels J Hofmeyr <ne...@elego.de>.
Neels J. Hofmeyr wrote:
> Hi Greg,
>
> r34258 breaks my --maintainer-mode build of trunk (ubuntu 8.10 i686) with
Sorry, Ubuntu 8.04.