PROBLEMS 8.0 KB

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