After removing the optimization switch completely and commenting out the BenchMarkAll() section, cryptest.exe will indeed compile. (Although it chokes a bit on validat2.cpp, it eventually works it out.)
Something I've noticed, though, is the rather dramatic increase in the size of libcryptopp.a. In 4.2, I generally got the size of the library down to 8.1 MB (4.7 MB after a "strip --strip-all"). With 5.0, I'm getting 25 MB (14 MB after stripping debugging symbols). Is that normal? I'm using the same system for both, same compilers and flags, etc. My system is Linux, 2.4.18 kernel, gcc 2.96, glibc 2.2.4. I'll try compiling on Solaris 8 SPARC and on Win2K in a bit and see what the results are... J On October 2, 2002 02:06 pm, Wei Dai wrote: > If it blows up even without -O2, then I guess there's nothing you can do > except comment out the BenchMarkAll() function in bench.cpp. You can do > that by changing "#if 1" on line 428 to "#if 0". > > On Wed, Oct 02, 2002 at 12:53:31PM -0400, J Smith wrote: > > Just tried giving Crypto++ 5.0 a try on a linux system using Red Hat's > > gcc 2.96 and it seems it doesn't like bench.cpp much at all. Everything > > else compiles fine, but when the make process gets to bench.cpp, the > > compiler goes nuts and starts sucking up all available memory and swap > > space until it explodes. After letting it sit for about 30 seconds, the > > cc1plus process has consumed pretty much all memory on my system (top > > shows it as having used 210 MB of physical memory, and it just keep using > > more). > > > > Eventually, I'm assuming it will just consume all available memory and > > die, but I ^C it before it happens. In any event, bench.cpp won't > > compile. I noticed this happened with Crypto++ 4.2 and Red Hat's gcc 2.96 > > if you use -O2 in CXXFLAGS. > > > > Anyway, is this a compiler bug? I'm assuming so, and if so, is there > > anything that can be done about it? > > > > Thanks. > > > > J
