Build failed in Jenkins: cyrus-imapd-master #652
Greg Banks
gnb at fastmail.fm
Wed Jun 20 02:28:34 EDT 2012
On Tue, Jun 19, 2012, at 11:17 PM, Дилян Палаузов wrote:
> Hello,
>
> I merged today the dev/libtool branch in master.
Ok, so the first problem is that you did a merge rather than rebase the
devllibtool branch on current master and then push that result. Merging
makes the commit graph really really messy and hard to follow, and it's
harder to debug problems resulting after the merge, like this one. In
particular it makes bisecting much harder. I know rebasing is a pain -
believe me I know - but merging instead is just wantonly invoking
technical debt, i.e. pushing the pain into the future.
> I have no idea, why autoreconf does not run cleanly on ci.cyrusimap.org
> and complains about missing RANLIB and LT_INIT. On my system there are
> no problems, libtool recommended to remove AC_PROG_RANLIB from
> configure.ac and LT_INIT is there.
>
> Can somebody with local access check why autoreconf does not run? A
> manual deletion of aclocal.m4 or autom4te.cache might solve the problem
> (or not).
I removed those files but autoreconf fails in exactly the same way - see
build #653.
The offending line in Makefile.am is
70 check_LIBRARIES =
and it should be noted that check_LIBRARIES is not used *anywhere*
anymore. Looking in git-blame I can see that this line was added by
you, in this commit
commit 18798292db946f9814a015120defab681a716a45
Author: Дилян Палаузов <git-dpa at aegee.org>
Date: Thu Apr 12 10:03:02 2012 +0000
Makefile.am: merge installsieve/Makefile.in
It is unclear why this directory exist, since there is no place,
that
installs installsieve.
but most of that commit has been removed again in subsequent commits.
So we don't seem to need that line anymore. It doesn't cause a warning
on my system either, go figure :( I removed that line, but build #654
is still broken.
The next problem is that autoreconf seems to be confused about libtool
bash-3.2$ autoreconf -v -i -f -Icmulocal
...
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
...
Makefile.am:70: Libtool library used but `LIBTOOL' is undefined
Makefile.am:70: The usual way to define `LIBTOOL' is to add `LT_INIT'
Makefile.am:70: to `configure.ac' and run `aclocal' and `autoconf'
again.
Makefile.am:70: If `LT_INIT' is in `configure.ac', make sure
Makefile.am:70: its definition is in aclocal's search path.
It turns out that the libtool on this machine is sufficiently old that
it doesn't define LT_INIT but instead has AC_PROG_LIBTOOL. Autoreconf
is happy to detect either, but advises you use LT_INIT. So I changed
configure.ac to use the older deprecated AC_PROG_LIBTOOL. This was a
terrible idea.
Then I remembered that we're not running with system autotools at all
but with ones I built, so I built and installed a more modern version of
libtool as well. This worked slightly better: build #656. We get lots
of these warning
configure.ac:121: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from...
autoconf/general.m4:2670: _AC_LINK_IFELSE is expanded from...
autoconf/general.m4:2680: AC_LINK_IFELSE is expanded from...
cmulocal/libtool.m4:5331: _LT_LINKER_SHLIBS is expanded from...
cmulocal/libtool.m4:5416: _LT_LANG_C_CONFIG is expanded from...
cmulocal/libtool.m4:240: _LT_SETUP is expanded from...
cmulocal/libtool.m4:104: LT_INIT is expanded from...
configure.ac:121: the top level
but then the build fails with
/bin/sh ./libtool --tag=CC --mode=link gcc -fPIC --coverage -g -O0
--coverage -L4.8/lib -Wl,-rpath,4.8/lib -o lib/libcyrus_min.la -rpath
/usr/cyrus/lib lib/assert.lo lib/hash.lo lib/imapopts.lo
lib/libconfig.lo lib/lock_fcntl.lo lib/mappedfile.lo lib/map_shared.lo
lib/mpool.lo lib/retry.lo lib/strarray.lo lib/strhash.lo lib/util.lo
lib/xmalloc.lo lib/xstrlcat.lo lib/xstrlcpy.lo -lgssapi_krb5 -lkrb5
-lk5crypto -lcom_err -lkrb5support -ldl -ldb-4.3 -lz
./libtool: line 5310: cd: 4.8/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `4.8/lib'
This seems to be a bug in the tools/jenkins-build.sh script which has
gone un-noticed for a long time, but which finally broke when libtool
was added. The script is running "configure --with-bdb=4.8", which
seems to have once worked as "figure out how to compile and link against
version 4.8 of the Bekerley DB library" but now means "the Berkeley DB
library can be found in the directory named '4.8/' ". Before libtool,
this resulted in broken -I and -L options which were silently ignored.
With libtool, the same broken option gives a build failure. So I
removed that configure argument.
At this point we the build goes all the way through to running tests,
and we get a single test failure
Cassandane::Cyrus::Sieve.test_badscript_timsieved (from
Cassandane__Cyrus__Sieve)
Failing for the past 1 build (Since Failed#657 )
Took 0.48 sec.
add description
Error Message
Boolean assertion failed
Stacktrace
test_badscript_timsieved(Cassandane::Cyrus::Sieve)
Boolean assertion failed at
/usr/lib/perl5/vendor_perl/5.8.8/Test/Unit/Exception.pm line 13
Test::Unit::Exception::throw_new('Test::Unit::Failure=HASH(0x44fbb30)',
'-package', 'Cassandane::Cyrus::Sieve', '-file',
'Cassandane/Cyrus/Sieve.pm', '-line', 290, '-object',
'Cassandane::Cyrus::Sieve=HASH(0x3ef2480)', ...) called at
/usr/lib/perl5/vendor_perl/5.8.8/Test/Unit/Assert.pm line 85
Test::Unit::Assert::do_assertion('Cassandane::Cyrus::Sieve=HASH(0x3ef2480)',
'Test::Unit::Assertion::Boolean=SCALAR(0x4679ee0)',
'Cassandane::Cyrus::Sieve', 'Cassandane/Cyrus/Sieve.pm', 290)
called at /usr/lib/perl5/vendor_perl/5.8.8/Test/Unit/Assert.pm
line 19
Test::Unit::Assert::assert('Cassandane::Cyrus::Sieve=HASH(0x3ef2480)')
called at Cassandane/Cyrus/Sieve.pm line 290
Cassandane::Cyrus::Sieve::badscript_common('Cassandane::Cyrus::Sieve=HASH(0x3ef2480)')
called at Cassandane/Cyrus/Sieve.pm line 365
Cassandane::Cyrus::Sieve::test_badscript_timsieved('Cassandane::Cyrus::Sieve=HASH(0x3ef2480)')
called at /usr/lib/perl5/vendor_perl/5.8.8/Test/Unit/TestCase.pm
line 75
[...framework calls elided...]
280 sub badscript_common
281 {
282 my ($self) = @_;
283
284 my $res;
285 my @errs;
286
287 ($res, @errs) = $self->compile_sieve_script('badrequire',
288 "require [\"nonesuch\"];\n");
289 $self->assert_str_equals('failure', $res);
290 $self->assert(grep m/Unsupported feature.*nonesuch/, @errs);
<---
291
In syslog we see
Jun 20 01:40:30 hudson-01 cassandane: =====> Cyrus::TestCase[180]
---------- BEGIN test_badscript_timsieved ----------
Jun 20 01:40:30 hudson-01 cassandane: =====> Cyrus::Sieve[363] Testing
sieve script compile failures, via timsieved
Jun 20 01:40:30 hudson-01 cassandane: =====> Cyrus::Sieve[185] Checking
preconditions for compiling sieve script badrequire
Jun 20 01:40:30 hudson-01 cassandane: =====> Cyrus::Sieve[203] Running
installsieve on script badrequire
Jun 20 01:40:30 hudson-01 cassandane: =====> Instance[1074] Running:
"/var/lib/jenkins/jobs/cyrus-imapd-master/workspace/inst/usr/cyrus/bin/installsieve"
"-i" "/var/tmp/cass/053333152/badrequire.script" "-u" "cassandane"
"127.0.0.1:9101"
Jun 20 01:40:30 hudson-01 cassandane: =====> Cyrus::Sieve[118] errors:
Jun 20 01:40:30 hudson-01 cassandane: =====> Cyrus::Sieve[119] perl:
symbol lookup error:
/var/lib/jenkins/jobs/cyrus-imapd-master/workspace/inst/usr/cyrus/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Cyrus/SIEVE/managesieve/managesieve.so:
undefined symbol: prot_new
Jun 20 01:40:30 hudson-01 053333152/sieve[26032]: Lost connection to
client -- exiting
Jun 20 01:40:30 hudson-01 cassandane: =====> Cyrus::TestCase[252]
---------- END test_badscript_timsieved ----------
which means that managesieve.so wasn't built right.
gnb at hudson-01 2008 nm
/var/lib/jenkins/jobs/cyrus-imapd-master/workspace/inst/usr/cyrus/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Cyrus/SIEVE/managesieve/managesieve.so
| grep prot
U prot_flush
U prot_free
U prot_getc
U prot_new
U prot_printf
U prot_setsasl
U prot_ungetc
U prot_write
It seems that prot.o, which is present in the perl/.libs/libcyrus.a
convenience library, wasn't linked into managesieve.so, despite other
object files from the same convenience library being linked in. This
seems to be an ordering problem
gcc --coverage -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic managesieve.o ../../../perl/.libs/libcyrus.a
../../../perl/.libs/libcyrus_min.a -o
blib/arch/auto/Cyrus/SIEVE/managesieve/managesieve.so ../lib/libisieve.a
\
Note that libisieve.a is *after* libcyrus.a. So I fixed that by using
MYEXTLIB instead of LDFROM in the Makefile.PLs, as you suggested.
Which...finally gave us a working build. Phew.
--
Greg.
More information about the Cyrus-devel
mailing list