1100936Snectar* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X. 2100936Snectar 3109998Smarkm 4109998Smarkm NOTE: The problem described here only applies when OpenSSL isn't built 5109998Smarkm with shared library support (i.e. without the "shared" configuration 6109998Smarkm option). If you build with shared library support, you will have no 7109998Smarkm problems as long as you set up DYLD_LIBRARY_PATH properly at all times. 8109998Smarkm 9109998Smarkm 10100936SnectarThis is really a misfeature in ld, which seems to look for .dylib libraries 11100936Snectaralong the whole library path before it bothers looking for .a libraries. This 12100936Snectarmeans that -L switches won't matter unless OpenSSL is built with shared 13100936Snectarlibrary support. 14100936Snectar 15142425SnectarThe workaround may be to change the following lines in apps/Makefile and 16142425Snectartest/Makefile: 17100936Snectar 18100936Snectar LIBCRYPTO=-L.. -lcrypto 19100936Snectar LIBSSL=-L.. -lssl 20100936Snectar 21100936Snectarto: 22100936Snectar 23100936Snectar LIBCRYPTO=../libcrypto.a 24100936Snectar LIBSSL=../libssl.a 25100936Snectar 26100936SnectarIt's possible that something similar is needed for shared library support 27100936Snectaras well. That hasn't been well tested yet. 28100936Snectar 29100936Snectar 30100936SnectarAnother solution that many seem to recommend is to move the libraries 31100936Snectar/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different 32100936Snectardirectory, build and install OpenSSL and anything that depends on your 33100936Snectarbuild, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their 34100936Snectaroriginal places. Note that the version numbers on those two libraries 35100936Snectarmay differ on your machine. 36100936Snectar 37100936Snectar 38100936SnectarAs long as Apple doesn't fix the problem with ld, this problem building 39215697SsimonOpenSSL will remain as is. Well, the problem was addressed in 0.9.8f by 40215697Ssimonpassing -Wl,-search_paths_first, but it's unknown if the flag was 41215697Ssimonsupported from the initial MacOS X release. 42100936Snectar 43101613Snectar 44101613Snectar* Parallell make leads to errors 45101613Snectar 46101613SnectarWhile running tests, running a parallell make is a bad idea. Many test 47101613Snectarscripts use the same name for output and input files, which means different 48101613Snectarwill interfere with each other and lead to test failure. 49101613Snectar 50101613SnectarThe solution is simple for now: don't run parallell make when testing. 51109998Smarkm 52109998Smarkm 53160814Ssimon* Bugs in gcc triggered 54109998Smarkm 55160814Ssimon- According to a problem report, there are bugs in gcc 3.0 that are 56160814Ssimon triggered by some of the code in OpenSSL, more specifically in 57160814Ssimon PEM_get_EVP_CIPHER_INFO(). The triggering code is the following: 58109998Smarkm 59109998Smarkm header+=11; 60109998Smarkm if (*header != '4') return(0); header++; 61109998Smarkm if (*header != ',') return(0); header++; 62109998Smarkm 63160814Ssimon What happens is that gcc might optimize a little too agressively, and 64160814Ssimon you end up with an extra incrementation when *header != '4'. 65109998Smarkm 66160814Ssimon We recommend that you upgrade gcc to as high a 3.x version as you can. 67109998Smarkm 68160814Ssimon- According to multiple problem reports, some of our message digest 69160814Ssimon implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64 70160814Ssimon and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while 71160814Ssimon latter - SHA one. 72160814Ssimon 73160814Ssimon The recomendation is to upgrade your compiler. This naturally applies to 74160814Ssimon other similar cases. 75160814Ssimon 76160814Ssimon- There is a subtle Solaris x86-specific gcc run-time environment bug, which 77160814Ssimon "falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug 78160814Ssimon manifests itself as Segmentation Fault upon early application start-up. 79160814Ssimon The problem can be worked around by patching the environment according to 80160814Ssimon http://www.openssl.org/~appro/values.c. 81160814Ssimon 82109998Smarkm* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler. 83109998Smarkm 84109998SmarkmAs subject suggests SHA-1 might perform poorly (4 times slower) 85109998Smarkmif compiled with WorkShop 6 compiler and -xarch=v9. The cause for 86109998Smarkmthis seems to be the fact that compiler emits multiplication to 87109998Smarkmperform shift operations:-( To work the problem around configure 88109998Smarkmwith './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'. 89111147Snectar 90111147Snectar* Problems with hp-parisc2-cc target when used with "no-asm" flag 91111147Snectar 92111147SnectarWhen using the hp-parisc2-cc target, wrong bignum code is generated. 93111147SnectarThis is due to the SIXTY_FOUR_BIT build being compiled with the +O3 94111147Snectaraggressive optimization. 95111147SnectarThe problem manifests itself by the BN_kronecker test hanging in an 96111147Snectarendless loop. Reason: the BN_kronecker test calls BN_generate_prime() 97111147Snectarwhich itself hangs. The reason could be tracked down to the bn_mul_comba8() 98111147Snectarfunction in bn_asm.c. At some occasions the higher 32bit value of r[7] 99111147Snectaris off by 1 (meaning: calculated=shouldbe+1). Further analysis failed, 100111147Snectaras no debugger support possible at +O3 and additional fprintf()'s 101111147Snectarintroduced fixed the bug, therefore it is most likely a bug in the 102111147Snectaroptimizer. 103111147SnectarThe bug was found in the BN_kronecker test but may also lead to 104111147Snectarfailures in other parts of the code. 105111147Snectar(See Ticket #426.) 106111147Snectar 107111147SnectarWorkaround: modify the target to +O2 when building with no-asm. 108111147Snectar 109120631Snectar* Problems building shared libraries on SCO OpenServer Release 5.0.6 110120631Snectar with gcc 2.95.3 111120631Snectar 112120631SnectarThe symptoms appear when running the test suite, more specifically 113120631Snectartest/ectest, with the following result: 114120631Snectar 115120631SnectarOSSL_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 116120631Snectarectest.c:186: ABORT 117120631Snectar 118120631SnectarThe cause of the problem seems to be that isxdigit(), called from 119120631SnectarBN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further 120120631Snectarinvestigation shows that any of the isxxx() macros return 0 on any 121120631Snectarinput. A direct look in the information array that the isxxx() use, 122120631Snectarcalled __ctype, shows that it contains all zeroes... 123120631Snectar 124120631SnectarTaking a look at the newly created libcrypto.so with nm, one can see 125120631Snectarthat the variable __ctype is defined in libcrypto's .bss (which 126120631Snectarexplains why it is filled with zeroes): 127120631Snectar 128120631Snectar$ nm -Pg libcrypto.so | grep __ctype 129120631Snectar__ctype B 0011659c 130120631Snectar__ctype2 U 131120631Snectar 132120631SnectarCuriously, __ctype2 is undefined, in spite of being declared in 133120631Snectar/usr/include/ctype.h in exactly the same way as __ctype. 134120631Snectar 135120631SnectarAny information helping to solve this issue would be deeply 136120631Snectarappreciated. 137120631Snectar 138120631SnectarNOTE: building non-shared doesn't come with this problem. 139160814Ssimon 140160814Ssimon* ULTRIX build fails with shell errors, such as "bad substitution" 141160814Ssimon and "test: argument expected" 142160814Ssimon 143160814SsimonThe problem is caused by ULTRIX /bin/sh supporting only original 144160814SsimonBourne shell syntax/semantics, and the trouble is that the vast 145160814Ssimonmajority is so accustomed to more modern syntax, that very few 146160814Ssimonpeople [if any] would recognize the ancient syntax even as valid. 147160814SsimonThis inevitably results in non-trivial scripts breaking on ULTRIX, 148160814Ssimonand OpenSSL isn't an exclusion. Fortunately there is workaround, 149160814Ssimonhire /bin/ksh to do the job /bin/sh fails to do. 150160814Ssimon 151160814Ssimon1. Trick make(1) to use /bin/ksh by setting up following environ- 152160814Ssimon ment variables *prior* you execute ./Configure and make: 153160814Ssimon 154160814Ssimon PROG_ENV=POSIX 155160814Ssimon MAKESHELL=/bin/ksh 156160814Ssimon export PROG_ENV MAKESHELL 157160814Ssimon 158160814Ssimon or if your shell is csh-compatible: 159160814Ssimon 160160814Ssimon setenv PROG_ENV POSIX 161160814Ssimon setenv MAKESHELL /bin/ksh 162160814Ssimon 163160814Ssimon2. Trick /bin/sh to use alternative expression evaluator. Create 164160814Ssimon following 'test' script for example in /tmp: 165160814Ssimon 166160814Ssimon #!/bin/ksh 167160814Ssimon ${0##*/} "$@" 168160814Ssimon 169160814Ssimon Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend* 170160814Ssimon your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter- 171160814Ssimon natively just replace system /bin/test and /bin/[ with the 172160814Ssimon above script. 173160814Ssimon 174160814Ssimon* hpux64-ia64-cc fails blowfish test. 175160814Ssimon 176160814SsimonCompiler bug, presumably at particular patch level. It should be noted 177160814Ssimonthat same compiler generates correct 32-bit code, a.k.a. hpux-ia64-cc 178160814Ssimontarget. Drop optimization level to +O2 when compiling 64-bit bf_skey.o. 179160814Ssimon 180160814Ssimon* no-engines generates errors. 181160814Ssimon 182160814SsimonUnfortunately, the 'no-engines' configuration option currently doesn't 183160814Ssimonwork properly. Use 'no-hw' and you'll will at least get no hardware 184160814Ssimonsupport. We'll see how we fix that on OpenSSL versions past 0.9.8. 185160814Ssimon 186160814Ssimon* 'make test' fails in BN_sqr [commonly with "error 139" denoting SIGSEGV] 187160814Ssimon if elder GNU binutils were deployed to link shared libcrypto.so. 188160814Ssimon 189160814SsimonAs subject suggests the failure is caused by a bug in elder binutils, 190160814Ssimoneither as or ld, and was observed on FreeBSD and Linux. There are two 191160814Ssimonoptions. First is naturally to upgrade binutils, the second one - to 192160814Ssimonreconfigure with additional no-sse2 [or 386] option passed to ./config. 193160814Ssimon 194160814Ssimon* If configured with ./config no-dso, toolkit still gets linked with -ldl, 195160814Ssimon which most notably poses a problem when linking with dietlibc. 196160814Ssimon 197160814SsimonWe don't have framework to associate -ldl with no-dso, therefore the only 198160814Ssimonway is to edit Makefile right after ./config no-dso and remove -ldl from 199160814SsimonEX_LIBS line. 200246772Sjkim 201246772Sjkim* hpux-parisc2-cc no-asm build fails with SEGV in ECDSA/DH. 202246772Sjkim 203246772SjkimCompiler bug, presumably at particular patch level. Remaining 204246772Sjkimhpux*-parisc*-cc configurations can be affected too. Drop optimization 205246772Sjkimlevel to +O2 when compiling bn_nist.o. 206246772Sjkim 207246772Sjkim* solaris64-sparcv9-cc link failure 208246772Sjkim 209246772SjkimSolaris 8 ar can fail to maintain symbol table in .a, which results in 210246772Sjkimlink failures. Apply 109147-09 or later or modify Makefile generated 211246772Sjkimby ./Configure solaris64-sparcv9-cc and replace RANLIB assignment with 212246772Sjkim 213246772Sjkim RANLIB= /usr/ccs/bin/ar rs 214