Let 'openssl req' fail if an argument to '-newkey' is not

[openssl.git] / PROBLEMS

diff --git a/PROBLEMS b/PROBLEMS
index 99a0779f9606ce2b100e1607e67b38f6c6da2e28..bf532d112b6f90420749e69bcf9f20bf9e55c287 100644 (file)
--- a/PROBLEMS
+++ b/PROBLEMS
@@ -1,5 +1,11 @@
 * System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
 * System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.

-[NOTE: This is currently undergoing tests, and may be removed soon]
+
+
+    NOTE: The problem described here only applies when OpenSSL isn't built
+    with shared library support (i.e. without the "shared" configuration
+    option).  If you build with shared library support, you will have no
+    problems as long as you set up DYLD_LIBRARY_PATH properly at all times.
+

 
 This is really a misfeature in ld, which seems to look for .dylib libraries
 along the whole library path before it bothers looking for .a libraries.  This
 
 This is really a misfeature in ld, which seems to look for .dylib libraries
 along the whole library path before it bothers looking for .a libraries.  This


@@ -20,6 +26,23 @@ to:
 It's possible that something similar is needed for shared library support
 as well.  That hasn't been well tested yet.
 
 It's possible that something similar is needed for shared library support
 as well.  That hasn't been well tested yet.
 

+
+Another solution that many seem to recommend is to move the libraries
+/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
+directory, build and install OpenSSL and anything that depends on your
+build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
+original places.  Note that the version numbers on those two libraries
+may differ on your machine.
+
+

 As long as Apple doesn't fix the problem with ld, this problem building
 OpenSSL will remain as is.
 
 As long as Apple doesn't fix the problem with ld, this problem building
 OpenSSL will remain as is.
 

+
+* Parallell make leads to errors
+
+While running tests, running a parallell make is a bad idea.  Many test
+scripts use the same name for output and input files, which means different
+will interfere with each other and lead to test failure.
+
+The solution is simple for now: don't run parallell make when testing.