I traced the failure to a presumed problem with STLport's [input] stream handling. The bottom line was that, in the Whirlpool test vector file, one of the input values was split across a 4KB boundary in the file (offset 0x26000)... and the STLport code (I assume) violated some assumption the CryptoPP validation code makes while it is reassembling its long input lines. Note that adding an extra character to the comment at the beginning of the test data file solves the problem.
In any case, after reporting this on the STLport Bugs forum, I was told that they don't really support 4.6.2 any longer, and that I should be using the un-released 5.0 BETA. So I did, and uncovered a couple of things that the STLport folks took care of... and the end result (besides everything building and the full CryptoPP verification suite running) is:
1) files.cpp needs to get the "EOF" definition from *somewhere*, presumably stdio.h... this wasn't a problem in STLport 4.6.2, probably because one of the other STLport files was either defining it or including stdio.h
2) Francois Dumont (one of the STLport authors/maintainers) says that "hash in the stlport namespace is a reserved word according the SGI specification" and that this caused him problems with VC6 (because of a compiler bug?). He goes on to suggest that "for partability reason CryptoPP should change hash in hash_ or something else, perhaps with a simple macro defined only for VC6".
The first is pretty clear-cut, the second is a bit more obscure... but I thought that the CryptoPP community should at least hear about this.
Robert Roessler http://www.rftp.com
