This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Again the build is broken :(
- From: Kris Van Hees <kris dot van dot hees at oracle dot com>
- To: frysk at sourceware dot org
- Date: Fri, 24 Aug 2007 01:50:11 -0400
- Subject: Again the build is broken :(
Again, we have a broken build with the following error:
<<part truncated because it is not relevant>>
Running autoconf ... for libunwind
Running aclocal ... for frysk-imports
Running autoconf ... for frysk-imports
Running automake ... for frysk-imports
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
tests/Makefile.am: installing `./compile'
tests/Makefile.am: installing `./depcomp'
common/frysk-common.ac:222: installing `./config.guess'
common/frysk-common.ac:222: installing `./config.sub'
common/Makefile.rules:101: variable `GEN_GCJ_LDADD' is defined but no program or
common/Makefile.rules:101: library has `GEN_GCJ' as canonic name (possible typo)
Makefile.am:40: `common/Makefile.rules' included from here
Problem in directory frysk-imports
../frysk_config/autogen.sh: line 57: ../frysk_config/configure: No such file or directory
The cause seems to be the following commit:
2007-08-23 Andrew Cagney <cagney@redhat.com>
* Makefile.rules (fryski, gij.sh): Delete targets.
I hope Mark or anyone else in a more convenient timezone may be able to commit
a fix for this. Still recovering a bit from my travel yesterday, I'm more
likely to cause additional problems than to solve this one right now.
Finally, it seems like we're getting a lot more broken build cases lately than
we've had in the past months. I am not sure what is causing this, because it
seems like there have not really been any procedural changes that would cause
this regression in quality. That leaves the question: what can we do about
this? Assuming pre-commit testing is being done appropriately (i.e. using a
clean slate - no left over configure scipts etc generated in a previous build),
a problem like this can only be the result of a problem in how we perform the
pre-commit testing. What can we do to improive upon it?
Cheers,
Kris