Bug #5108

libxml2 build

Added by Lynn Garren over 6 years ago. Updated about 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
SSI Package:


build_libxml2 seems to fail the first time when it runs the tests. If you run it again with no changes, it succeeds.
This is on cluck as called by buildLar in a clean directory.


#1 Updated by Christopher Green over 6 years ago

  • Status changed from New to Feedback

Can this be reproduced in a clean way?

#2 Updated by Christopher Green over 6 years ago

  • Status changed from Feedback to Assigned
  • Assignee set to Lynn Garren
  • Target version changed from 1.09.00 to 493
  • Start date deleted (12/17/2013)

[ Report from Brett Viren 2014/01/16 ]

[ -d test   ] || ln -s /data3/bv/lbne/w/install/products/libxml2/v2_9_1/source/libxml2-2.9.1/test   .
[ -d result ] || ln -s /data3/bv/lbne/w/install/products/libxml2/v2_9_1/source/libxml2-2.9.1/result .
./runtest &&  ./testrecurse && ./testapi &&  ./testchar&&  ./testdict &&  ./runxmlconf
Error for ./test/errors/name2.xml failed
File ./test/errors/name2.xml generated an error

I then find in the libxml2 build area:

bvdb@daya0009:v2_9_1> less ./build/Linux64bit+2.6-2.12-prof/result/errors/name2.xml.str 
./test/errors/name2.xml:2: parser error : Specification mandate value for attribute fooooooooooooooooooooo.....

./test/errors/name2.xml:2: parser error : attributes construct error

./test/errors/name2.xml:2: parser error : Couldn't find end of Start Tag foo

./test/errors/name2.xml : failed to parse

Note, those "ooooo"s continue for many lines and I truncate here to save space.

Simply rerunning the build causes "success", that is, the build gets
past libxml2. But I suspect this may really be "passing" because the
idempotency is being defeated. The log file does show that "make check"
is run again so if this is a false success it's glossed over inside
libxml2 and not at the level.

Eventually I'll redo this green field build and we'll see if this
failure persists, but if any of this rings a bell, please let me know.

#3 Updated by Brett Viren over 6 years ago

Google finds we are not alone:

Unfortunately, no real conclusion was reached in that thread other than
"I think that this is issue only with tests."

#4 Updated by Christopher Green over 6 years ago

  • Target version changed from 493 to 1.09.00

#5 Updated by Lynn Garren over 6 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Since the problem appears to be a semi-functional test supplied by libxml2, we have disabled the check on the output of the test. The latest libxml2 2.9.1 source code tarball reflects this change.

#6 Updated by Christopher Green about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF