PROBLEMS

   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 * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
  75
  76 As subject suggests SHA-1 might perform poorly (4 times slower)
  77 if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
  78 this seems to be the fact that compiler emits multiplication to
  79 perform shift operations:-( To work the problem around configure
  80 with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
  81
  82 * Problems with hp-parisc2-cc target when used with "no-asm" flag
  83
  84 When using the hp-parisc2-cc target, wrong bignum code is generated.
  85 This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
  86 aggressive optimization.
  87 The problem manifests itself by the BN_kronecker test hanging in an
  88 endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
  89 which itself hangs. The reason could be tracked down to the bn_mul_comba8()
  90 function in bn_asm.c. At some occasions the higher 32bit value of r[7]
  91 is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
  92 as no debugger support possible at +O3 and additional fprintf()'s
  93 introduced fixed the bug, therefore it is most likely a bug in the
  94 optimizer.
  95 The bug was found in the BN_kronecker test but may also lead to
  96 failures in other parts of the code.
  97 (See Ticket #426.)
  98
  99 Workaround: modify the target to +O2 when building with no-asm.
 100
 101 * Problems building shared libraries on SCO OpenServer Release 5.0.6
 102   with gcc 2.95.3
 103
 104 The symptoms appear when running the test suite, more specifically
 105 test/ectest, with the following result:
 106
 107 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
 108 ectest.c:186: ABORT
 109
 110 The cause of the problem seems to be that isxdigit(), called from
 111 BN_hex2bn(), returns 0 on a perfectly legitimate hex digit.  Further
 112 investigation shows that any of the isxxx() macros return 0 on any
 113 input.  A direct look in the information array that the isxxx() use,
 114 called __ctype, shows that it contains all zeroes...
 115
 116 Taking a look at the newly created libcrypto.so with nm, one can see
 117 that the variable __ctype is defined in libcrypto's .bss (which
 118 explains why it is filled with zeroes):
 119
 120 $ nm -Pg libcrypto.so | grep __ctype
 121 __ctype B 0011659c
 122 __ctype2 U
 123
 124 Curiously, __ctype2 is undefined, in spite of being declared in
 125 /usr/include/ctype.h in exactly the same way as __ctype.
 126
 127 Any information helping to solve this issue would be deeply
 128 appreciated.
 129
 130 NOTE: building non-shared doesn't come with this problem.
 131
 132 * ULTRIX build fails with shell errors, such as "bad substitution"
 133   and "test: argument expected"
 134
 135 The problem is caused by ULTRIX /bin/sh supporting only original
 136 Bourne shell syntax/semantics, and the trouble is that the vast
 137 majority is so accustomed to more modern syntax, that very few
 138 people [if any] would recognize the ancient syntax even as valid.
 139 This inevitably results in non-trivial scripts breaking on ULTRIX,
 140 and OpenSSL isn't an exclusion. Fortunately there is workaround,
 141 hire /bin/ksh to do the job /bin/sh fails to do.
 142
 143 1. Trick make(1) to use /bin/ksh by setting up following environ-
 144    ment variables *prior* you execute ./Configure and make:
 145
 146         PROG_ENV=POSIX
 147         MAKESHELL=/bin/ksh
 148         export PROG_ENV MAKESHELL
 149
 150    or if your shell is csh-compatible:
 151
 152         setenv PROG_ENV POSIX
 153         setenv MAKESHELL /bin/ksh
 154
 155 2. Trick /bin/sh to use alternative expression evaluator. Create
 156    following 'test' script for example in /tmp:
 157
 158         #!/bin/ksh
 159         ${0##*/} "$@"
 160
 161    Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend*
 162    your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter-
 163    natively just replace system /bin/test and /bin/[ with the
 164    above script.