Merge branch 'rsalz-docfixes'
[openssl.git] / PROBLEMS
index 8301624639a1cbc3d919c9cdab6c45b26ec6ef4a..3eaab01f2ce4676affe26ebe3f30e5228e603ce0 100644 (file)
--- a/PROBLEMS
+++ b/PROBLEMS
@@ -12,8 +12,8 @@ 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.
 
-The workaround may be to change the following lines in apps/Makefile.ssl and
-test/Makefile.ssl:
+The workaround may be to change the following lines in apps/Makefile and
+test/Makefile:
 
   LIBCRYPTO=-L.. -lcrypto
   LIBSSL=-L.. -lssl
 
   LIBCRYPTO=-L.. -lcrypto
   LIBSSL=-L.. -lssl
@@ -36,7 +36,9 @@ may differ on your machine.
 
 
 As long as Apple doesn't fix the problem with ld, this problem building
 
 
 As long as Apple doesn't fix the problem with ld, this problem building
-OpenSSL will remain as is.
+OpenSSL will remain as is. Well, the problem was addressed in 0.9.8f by
+passing -Wl,-search_paths_first, but it's unknown if the flag was
+supported from the initial MacOS X release.
 
 
 * Parallell make leads to errors
 
 
 * Parallell make leads to errors
@@ -48,20 +50,34 @@ will interfere with each other and lead to test failure.
 The solution is simple for now: don't run parallell make when testing.
 
 
 The solution is simple for now: don't run parallell make when testing.
 
 
-* Bugs in gcc 3.0 triggered
+* Bugs in gcc 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:
+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++;
 
 
        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'.
+  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.
+  We recommend that you upgrade gcc to as high a 3.x version as you can.
+
+- According to multiple problem reports, some of our message digest
+  implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64
+  and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while
+  latter - SHA one.
+
+  The recomendation is to upgrade your compiler. This naturally applies to
+  other similar cases.
+
+- There is a subtle Solaris x86-specific gcc run-time environment bug, which
+  "falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug
+  manifests itself as Segmentation Fault upon early application start-up.
+  The problem can be worked around by patching the environment according to
+  http://www.openssl.org/~appro/values.c.
 
 * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
 
 
 * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
 
@@ -120,3 +136,78 @@ Any information helping to solve this issue would be deeply
 appreciated.
 
 NOTE: building non-shared doesn't come with this problem.
 appreciated.
 
 NOTE: building non-shared doesn't come with this problem.
+
+* ULTRIX build fails with shell errors, such as "bad substitution"
+  and "test: argument expected"
+
+The problem is caused by ULTRIX /bin/sh supporting only original
+Bourne shell syntax/semantics, and the trouble is that the vast
+majority is so accustomed to more modern syntax, that very few
+people [if any] would recognize the ancient syntax even as valid.
+This inevitably results in non-trivial scripts breaking on ULTRIX,
+and OpenSSL isn't an exclusion. Fortunately there is workaround,
+hire /bin/ksh to do the job /bin/sh fails to do.
+
+1. Trick make(1) to use /bin/ksh by setting up following environ-
+   ment variables *prior* you execute ./Configure and make:
+
+       PROG_ENV=POSIX
+       MAKESHELL=/bin/ksh
+       export PROG_ENV MAKESHELL
+
+   or if your shell is csh-compatible:
+
+       setenv PROG_ENV POSIX
+       setenv MAKESHELL /bin/ksh
+
+2. Trick /bin/sh to use alternative expression evaluator. Create
+   following 'test' script for example in /tmp:
+
+       #!/bin/ksh
+       ${0##*/} "$@"
+
+   Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend*
+   your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter-
+   natively just replace system /bin/test and /bin/[ with the
+   above script.
+
+* hpux64-ia64-cc fails blowfish test.
+
+Compiler bug, presumably at particular patch level. It should be noted
+that same compiler generates correct 32-bit code, a.k.a. hpux-ia64-cc
+target. Drop optimization level to +O2 when compiling 64-bit bf_skey.o.
+
+* no-engines generates errors.
+
+Unfortunately, the 'no-engines' configuration option currently doesn't
+work properly.  Use 'no-hw' and you'll will at least get no hardware
+support.  We'll see how we fix that on OpenSSL versions past 0.9.8.
+
+* 'make test' fails in BN_sqr [commonly with "error 139" denoting SIGSEGV]
+  if elder GNU binutils were deployed to link shared libcrypto.so.
+
+As subject suggests the failure is caused by a bug in elder binutils,
+either as or ld, and was observed on FreeBSD and Linux. There are two
+options. First is naturally to upgrade binutils, the second one - to
+reconfigure with additional no-sse2 [or 386] option passed to ./config.
+
+* If configured with ./config no-dso, toolkit still gets linked with -ldl,
+  which most notably poses a problem when linking with dietlibc.
+
+We don't have framework to associate -ldl with no-dso, therefore the only
+way is to edit Makefile right after ./config no-dso and remove -ldl from
+EX_LIBS line.
+
+* hpux-parisc2-cc no-asm build fails with SEGV in ECDSA/DH.
+
+Compiler bug, presumably at particular patch level. Remaining
+hpux*-parisc*-cc configurations can be affected too. Drop optimization
+level to +O2 when compiling bn_nist.o.
+
+* solaris64-sparcv9-cc link failure
+
+Solaris 8 ar can fail to maintain symbol table in .a, which results in
+link failures. Apply 109147-09 or later or modify Makefile generated
+by ./Configure solaris64-sparcv9-cc and replace RANLIB assignment with
+
+       RANLIB= /usr/ccs/bin/ar rs