Avoid a.out name table pollition.
[openssl.git] / PROBLEMS
index 4bf31303be998a94a9b4044801ed443cdc725208..85e96a5ebebc9511f1bf58dcc205a0122d0a9623 100644 (file)
--- a/PROBLEMS
+++ b/PROBLEMS
@@ -70,3 +70,62 @@ 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.
+
+* Problems building shared libraries on SCO OpenServer Release 5.0.6
+  with gcc 2.95.3
+
+The symptoms appear when running the test suite, more specifically
+test/ectest, with the following result:
+
+OSSL_LIBPATH="`cd ..; pwd`"; LD_LIBRARY_PATH="$OSSL_LIBPATH:$LD_LIBRARY_PATH"; DYLD_LIBRARY_PATH="$OSSL_LIBPATH:$DYLD_LIBRARY_PATH"; SHLIB_PATH="$OSSL_LIBPATH:$SHLIB_PATH"; LIBPATH="$OSSL_LIBPATH:$LIBPATH"; if [ "debug-sco5-gcc" = "Cygwin" ]; then PATH="${LIBPATH}:$PATH"; fi; export LD_LIBRARY_PATH DYLD_LIBRARY_PATH SHLIB_PATH LIBPATH PATH; ./ectest
+ectest.c:186: ABORT
+
+The cause of the problem seems to be that isxdigit(), called from
+BN_hex2bn(), returns 0 on a perfectly legitimate hex digit.  Further
+investigation shows that any of the isxxx() macros return 0 on any
+input.  A direct look in the information array that the isxxx() use,
+called __ctype, shows that it contains all zeroes...
+
+Taking a look at the newly created libcrypto.so with nm, one can see
+that the variable __ctype is defined in libcrypto's .bss (which
+explains why it is filled with zeroes):
+
+$ nm -Pg libcrypto.so | grep __ctype
+__ctype B 0011659c
+__ctype2 U         
+
+Curiously, __ctype2 is undefined, in spite of being declared in
+/usr/include/ctype.h in exactly the same way as __ctype.
+
+Any information helping to solve this issue would be deeply
+appreciated.
+
+NOTE: building non-shared doesn't come with this problem.