X-Git-Url: https://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff_plain;f=PROBLEMS;h=3eaab01f2ce4676affe26ebe3f30e5228e603ce0;hp=1a956b54815c9c794d5a3982a68f2cce53cd484b;hb=dcca7b13e9066443237dd3001ae52fd103151c98;hpb=04da4558dd70add8069d90ef7c1a5dd17c7b76c2 diff --git a/PROBLEMS b/PROBLEMS index 1a956b5481..3eaab01f2c 100644 --- 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. -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 @@ -36,7 +36,9 @@ may differ on your machine. 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 @@ -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. -* 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++; -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. @@ -90,11 +106,108 @@ failures in other parts of the code. Workaround: modify the target to +O2 when building with no-asm. -* Poor support for AIX shared builds. +* 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. + +* 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 -do_aix-shared rule is not flexible enough to parameterize through a -config-line. './Configure aix43-cc shared' is working, but not -'./Configure aix64-gcc shared'. In latter case make fails to create shared -libraries. It's possible to build 64-bit shared libraries by running -'env OBJECT_MODE=64 make', but we need more elegant solution. Preferably one -supporting even gcc shared builds. See RT#463 for background information. + RANLIB= /usr/ccs/bin/ar rs