fix EC_GROUP_copy for EC_GFp_nist_method()

[openssl.git] / PROBLEMS

diff --git a/PROBLEMS b/PROBLEMS
index b1981d8bd69b7f5ef7225fe7d9d0c92d387b0467..1a956b54815c9c794d5a3982a68f2cce53cd484b 100644 (file)
--- a/PROBLEMS
+++ b/PROBLEMS
@@ -1,8 +1,14 @@
 * 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]

 
 

-This is really a bug in ld, which seems to look for .dylib libraries along
-the whole library path before it bothers looking for .a libraries.  This
+
+    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

 means that -L switches won't matter unless OpenSSL is built with shared
 library support.
 
 means that -L switches won't matter unless OpenSSL is built with shared
 library support.
 


@@ -20,6 +26,75 @@ 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.
+
+
+* Bugs in gcc 3.0 triggered
+
+According to a problem report, there are bugs in gcc 3.0 that are
+triggered by some of the code in OpenSSL, more specifically in
+PEM_get_EVP_CIPHER_INFO().  The triggering code is the following:
+
+       header+=11;
+       if (*header != '4') return(0); header++;
+       if (*header != ',') return(0); header++;
+
+What happens is that gcc might optimize a little too agressively, and
+you end up with an extra incrementation when *header != '4'.
+
+We recommend that you upgrade gcc to as high a 3.x version as you can.
+
+* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
+
+As subject suggests SHA-1 might perform poorly (4 times slower)
+if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
+this seems to be the fact that compiler emits multiplication to
+perform shift operations:-( To work the problem around configure
+with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
+
+* Problems with hp-parisc2-cc target when used with "no-asm" flag
+
+When using the hp-parisc2-cc target, wrong bignum code is generated.
+This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
+aggressive optimization.
+The problem manifests itself by the BN_kronecker test hanging in an
+endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
+which itself hangs. The reason could be tracked down to the bn_mul_comba8()
+function in bn_asm.c. At some occasions the higher 32bit value of r[7]
+is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
+as no debugger support possible at +O3 and additional fprintf()'s
+introduced fixed the bug, therefore it is most likely a bug in the
+optimizer.
+The bug was found in the BN_kronecker test but may also lead to
+failures in other parts of the code.
+(See Ticket #426.)
+
+Workaround: modify the target to +O2 when building with no-asm.
+
+* Poor support for AIX shared builds.
+
+do_aix-shared rule is not flexible enough to parameterize through a
+config-line. './Configure aix43-cc shared' is working, but not
+'./Configure aix64-gcc shared'. In latter case make fails to create shared
+libraries. It's possible to build 64-bit shared libraries by running
+'env OBJECT_MODE=64 make', but we need more elegant solution. Preferably one
+supporting even gcc shared builds. See RT#463 for background information.