Change the FAQ entry a bit, giving the details as I observed them.

diff --git a/FAQ b/FAQ
index f29ac5c46ab65737c2341715f7c4fa4aeba890c3..fa44480c83410c2e7781637976a57d83d4e3bd17 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -133,6 +133,13 @@ the "PRNG not seeded" error message may occur.
 when trying to password-encrypt an RSA key!  This is a bug in the
 library; try a later version instead.]
 
 when trying to password-encrypt an RSA key!  This is a bug in the
 library; try a later version instead.]
 

+For Solaris 2.6, Tim Nibbe <tnibbe@sprint.net> and others have suggested
+installing the SUNski package from Sun patch 105710-01 (Sparc) which
+adds a /dev/random device and make sure it gets used, usually through
+$RANDFILE.  There are probably similar patches for the other Solaris
+versions.  However, be warned that /dev/random is usually a blocking
+device, which may have som effects on OpenSSL.
+

 
 * Why does the linker complain about undefined symbols?
 
 
 * Why does the linker complain about undefined symbols?
 


@@ -330,9 +337,14 @@ be safely used.
 
 On some Alpha installations running True64 Unix and Compaq C, the compilation
 of crypto/sha/sha_dgst.c fails with the message 'Fatal:  Insufficient virtual
 
 On some Alpha installations running True64 Unix and Compaq C, the compilation
 of crypto/sha/sha_dgst.c fails with the message 'Fatal:  Insufficient virtual

-memory to continue compilation.'  It's currently unknown why this happens,
-except that it has to do with optimization.  The very quick solution would
-be to compile everything with -O0 as optimization level, but that's not a very
+memory to continue compilation.'  As far as the tests have shown, this is a
+compiler bug.  What happens is that it eats up resident memory (not the swap)
+until the current limit is reached and then dies with the error message given
+above.  The bug in question is clearly in the optimization code, because if
+one eliminates optimization completely (-O0), the compilation goes through
+(and the compiler consumes about 2MB of resident memory instead of 128MB or
+whatever one's limit is currently).  The very quick solution would be to
+compile everything with -O0 as optimization level, but that's not a very

 nice thing to do for those who expect to get the best result from OpenSSL.
 A bit more complicated solution is the following:
 
 nice thing to do for those who expect to get the best result from OpenSSL.
 A bit more complicated solution is the following: