X-Git-Url: https://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff_plain;f=PROBLEMS;h=1a956b54815c9c794d5a3982a68f2cce53cd484b;hp=f072449feca8c77565299c1c1522a018e9eedb62;hb=520b76ffd95cb27839471055fa4950ff9bf50be2;hpb=ebccb429def24678e2a12b92e31cabb5a60605e8

diff --git a/PROBLEMS b/PROBLEMS
index f072449fec..1a956b5481 100644
--- a/PROBLEMS
+++ b/PROBLEMS
@@ -1,5 +1,11 @@
 * 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
@@ -32,3 +38,63 @@ may differ on your machine.
 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.