X-Git-Url: https://git.openssl.org/?p=openssl.git;a=blobdiff_plain;f=PROBLEMS;h=8301624639a1cbc3d919c9cdab6c45b26ec6ef4a;hp=d78e2d9a23c43c434c6f6369049662daff25b701;hb=2dc08d5f5da62d2f34acd39370f3b9ed7c0b0042;hpb=7dfb0b774e6592dcbfe47015168a0ac8b44e2a17 diff --git a/PROBLEMS b/PROBLEMS index d78e2d9a23..8301624639 100644 --- a/PROBLEMS +++ b/PROBLEMS @@ -1,50 +1,122 @@ -If you have any problems with SSLeay then please take the following -steps: +* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X. - Remove the ASM version of the BN routines (edit Configure) - Remove the compiler optimisation flags - Add in the compiler debug flags (-g) -Note: if using gcc then remove -fomit-frame-pointer before you try - to debug things. + NOTE: The problem described here only applies when OpenSSL isn't built + with shared library support (i.e. without the "shared" configuration + option). If you build with shared library support, you will have no + problems as long as you set up DYLD_LIBRARY_PATH properly at all times. -If you wish to report a bug then please include the following information -in any bug report: - SSLeay Details - - Version, most of these details can be got from the - 'ssleay version -a' command. - Operating System Details - - OS Name - - OS Version - - Hardware platform - Compiler Details - - Name - - Version - Application Details - - Name - - Version - Problem Description - - include steps that will reproduce the problem (if known) - Stack Traceback (if the application dumps core) +This is really a misfeature in ld, which seems to look for .dylib libraries +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. -For example: +The workaround may be to change the following lines in apps/Makefile.ssl and +test/Makefile.ssl: - SSLeay-0.5.1a - SunOS 5.3, SPARC, SunC 3.0 - SSLtelnet-0.7 + LIBCRYPTO=-L.. -lcrypto + LIBSSL=-L.. -lssl - Core dumps when using telnet with SSL support in bn_mul() with - the following stack trackback - ... +to: + LIBCRYPTO=../libcrypto.a + LIBSSL=../libssl.a -Report the bug to either - ssleay@mincom.oz.au (Eric and Tim) -or - ssl-bugs@mincom.oz.au (mailing list of active developers) +It's possible that something similar is needed for shared library support +as well. That hasn't been well tested yet. -Tim Hudson -tjh@mincom.oz.au +Another solution that many seem to recommend is to move the libraries +/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different +directory, build and install OpenSSL and anything that depends on your +build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their +original places. Note that the version numbers on those two libraries +may differ on your machine. + +As long as Apple doesn't fix the problem with ld, this problem building +OpenSSL will remain as is. + + +* Parallell make leads to errors + +While running tests, running a parallell make is a bad idea. Many test +scripts use the same name for output and input files, which means different +will interfere with each other and lead to test failure. + +The solution is simple for now: don't run parallell make when testing. + + +* Bugs in gcc 3.0 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: + + 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'. + +We recommend that you upgrade gcc to as high a 3.x version as you can. + +* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler. + +As subject suggests SHA-1 might perform poorly (4 times slower) +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. + +* 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.