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