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.
#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 (
[ 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 build_libxml2.sh 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."
#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.