1: * System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
    2: 
    3: 
    4:     NOTE: The problem described here only applies when OpenSSL isn't built
    5:     with shared library support (i.e. without the "shared" configuration
    6:     option).  If you build with shared library support, you will have no
    7:     problems as long as you set up DYLD_LIBRARY_PATH properly at all times.
    8: 
    9: 
   10: This is really a misfeature in ld, which seems to look for .dylib libraries
   11: along the whole library path before it bothers looking for .a libraries.  This
   12: means that -L switches won't matter unless OpenSSL is built with shared
   13: library support.
   14: 
   15: The workaround may be to change the following lines in apps/Makefile and
   16: test/Makefile:
   17: 
   18:   LIBCRYPTO=-L.. -lcrypto
   19:   LIBSSL=-L.. -lssl
   20: 
   21: to:
   22: 
   23:   LIBCRYPTO=../libcrypto.a
   24:   LIBSSL=../libssl.a
   25: 
   26: It's possible that something similar is needed for shared library support
   27: as well.  That hasn't been well tested yet.
   28: 
   29: 
   30: Another solution that many seem to recommend is to move the libraries
   31: /usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
   32: directory, build and install OpenSSL and anything that depends on your
   33: build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
   34: original places.  Note that the version numbers on those two libraries
   35: may differ on your machine.
   36: 
   37: 
   38: As long as Apple doesn't fix the problem with ld, this problem building
   39: OpenSSL will remain as is.
   40: 
   41: 
   42: * Parallell make leads to errors
   43: 
   44: While running tests, running a parallell make is a bad idea.  Many test
   45: scripts use the same name for output and input files, which means different
   46: will interfere with each other and lead to test failure.
   47: 
   48: The solution is simple for now: don't run parallell make when testing.
   49: 
   50: 
   51: * Bugs in gcc triggered
   52: 
   53: - According to a problem report, there are bugs in gcc 3.0 that are
   54:   triggered by some of the code in OpenSSL, more specifically in
   55:   PEM_get_EVP_CIPHER_INFO().  The triggering code is the following:
   56: 
   57:         header+=11;
   58:         if (*header != '4') return(0); header++;
   59:         if (*header != ',') return(0); header++;
   60: 
   61:   What happens is that gcc might optimize a little too agressively, and
   62:   you end up with an extra incrementation when *header != '4'.
   63: 
   64:   We recommend that you upgrade gcc to as high a 3.x version as you can.
   65: 
   66: - According to multiple problem reports, some of our message digest
   67:   implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64
   68:   and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while
   69:   latter - SHA one.
   70: 
   71:   The recomendation is to upgrade your compiler. This naturally applies to
   72:   other similar cases.
   73: 
   74: - There is a subtle Solaris x86-specific gcc run-time environment bug, which
   75:   "falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug
   76:   manifests itself as Segmentation Fault upon early application start-up.
   77:   The problem can be worked around by patching the environment according to
   78:   http://www.openssl.org/~appro/values.c.
   79: 
   80: * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
   81: 
   82: As subject suggests SHA-1 might perform poorly (4 times slower)
   83: if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
   84: this seems to be the fact that compiler emits multiplication to
   85: perform shift operations:-( To work the problem around configure
   86: with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
   87: 
   88: * Problems with hp-parisc2-cc target when used with "no-asm" flag
   89: 
   90: When using the hp-parisc2-cc target, wrong bignum code is generated.
   91: This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
   92: aggressive optimization.
   93: The problem manifests itself by the BN_kronecker test hanging in an
   94: endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
   95: which itself hangs. The reason could be tracked down to the bn_mul_comba8()
   96: function in bn_asm.c. At some occasions the higher 32bit value of r[7]
   97: is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
   98: as no debugger support possible at +O3 and additional fprintf()'s
   99: introduced fixed the bug, therefore it is most likely a bug in the
  100: optimizer.
  101: The bug was found in the BN_kronecker test but may also lead to
  102: failures in other parts of the code.
  103: (See Ticket #426.)
  104: 
  105: Workaround: modify the target to +O2 when building with no-asm.
  106: 
  107: * Problems building shared libraries on SCO OpenServer Release 5.0.6
  108:   with gcc 2.95.3
  109: 
  110: The symptoms appear when running the test suite, more specifically
  111: test/ectest, with the following result:
  112: 
  113: 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
  114: ectest.c:186: ABORT
  115: 
  116: The cause of the problem seems to be that isxdigit(), called from
  117: BN_hex2bn(), returns 0 on a perfectly legitimate hex digit.  Further
  118: investigation shows that any of the isxxx() macros return 0 on any
  119: input.  A direct look in the information array that the isxxx() use,
  120: called __ctype, shows that it contains all zeroes...
  121: 
  122: Taking a look at the newly created libcrypto.so with nm, one can see
  123: that the variable __ctype is defined in libcrypto's .bss (which
  124: explains why it is filled with zeroes):
  125: 
  126: $ nm -Pg libcrypto.so | grep __ctype
  127: __ctype B 0011659c
  128: __ctype2 U         
  129: 
  130: Curiously, __ctype2 is undefined, in spite of being declared in
  131: /usr/include/ctype.h in exactly the same way as __ctype.
  132: 
  133: Any information helping to solve this issue would be deeply
  134: appreciated.
  135: 
  136: NOTE: building non-shared doesn't come with this problem.
  137: 
  138: * ULTRIX build fails with shell errors, such as "bad substitution"
  139:   and "test: argument expected"
  140: 
  141: The problem is caused by ULTRIX /bin/sh supporting only original
  142: Bourne shell syntax/semantics, and the trouble is that the vast
  143: majority is so accustomed to more modern syntax, that very few
  144: people [if any] would recognize the ancient syntax even as valid.
  145: This inevitably results in non-trivial scripts breaking on ULTRIX,
  146: and OpenSSL isn't an exclusion. Fortunately there is workaround,
  147: hire /bin/ksh to do the job /bin/sh fails to do.
  148: 
  149: 1. Trick make(1) to use /bin/ksh by setting up following environ-
  150:    ment variables *prior* you execute ./Configure and make:
  151: 
  152:         PROG_ENV=POSIX
  153:         MAKESHELL=/bin/ksh
  154:         export PROG_ENV MAKESHELL
  155: 
  156:    or if your shell is csh-compatible:
  157: 
  158:         setenv PROG_ENV POSIX
  159:         setenv MAKESHELL /bin/ksh
  160: 
  161: 2. Trick /bin/sh to use alternative expression evaluator. Create
  162:    following 'test' script for example in /tmp:
  163: 
  164:         #!/bin/ksh
  165:         ${0##*/} "$@"
  166: 
  167:    Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend*
  168:    your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter-
  169:    natively just replace system /bin/test and /bin/[ with the
  170:    above script.
  171: 
  172: * hpux64-ia64-cc fails blowfish test.
  173: 
  174: Compiler bug, presumably at particular patch level. It should be noted
  175: that same compiler generates correct 32-bit code, a.k.a. hpux-ia64-cc
  176: target. Drop optimization level to +O2 when compiling 64-bit bf_skey.o.
  177: 
  178: * no-engines generates errors.
  179: 
  180: Unfortunately, the 'no-engines' configuration option currently doesn't
  181: work properly.  Use 'no-hw' and you'll will at least get no hardware
  182: support.  We'll see how we fix that on OpenSSL versions past 0.9.8.
  183: 
  184: * 'make test' fails in BN_sqr [commonly with "error 139" denoting SIGSEGV]
  185:   if elder GNU binutils were deployed to link shared libcrypto.so.
  186: 
  187: As subject suggests the failure is caused by a bug in elder binutils,
  188: either as or ld, and was observed on FreeBSD and Linux. There are two
  189: options. First is naturally to upgrade binutils, the second one - to
  190: reconfigure with additional no-sse2 [or 386] option passed to ./config.
  191: 
  192: * If configured with ./config no-dso, toolkit still gets linked with -ldl,
  193:   which most notably poses a problem when linking with dietlibc.
  194: 
  195: We don't have framework to associate -ldl with no-dso, therefore the only
  196: way is to edit Makefile right after ./config no-dso and remove -ldl from
  197: EX_LIBS line.