PROBLEMS revision 120631
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.ssl and 16test/Makefile.ssl: 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. 40 41 42* Parallell make leads to errors 43 44While running tests, running a parallell make is a bad idea. Many test 45scripts use the same name for output and input files, which means different 46will interfere with each other and lead to test failure. 47 48The solution is simple for now: don't run parallell make when testing. 49 50 51* Bugs in gcc 3.0 triggered 52 53According to a problem report, there are bugs in gcc 3.0 that are 54triggered by some of the code in OpenSSL, more specifically in 55PEM_get_EVP_CIPHER_INFO(). The triggering code is the following: 56 57 header+=11; 58 if (*header != '4') return(0); header++; 59 if (*header != ',') return(0); header++; 60 61What happens is that gcc might optimize a little too agressively, and 62you end up with an extra incrementation when *header != '4'. 63 64We recommend that you upgrade gcc to as high a 3.x version as you can. 65 66* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler. 67 68As subject suggests SHA-1 might perform poorly (4 times slower) 69if compiled with WorkShop 6 compiler and -xarch=v9. The cause for 70this seems to be the fact that compiler emits multiplication to 71perform shift operations:-( To work the problem around configure 72with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'. 73 74* Problems with hp-parisc2-cc target when used with "no-asm" flag 75 76When using the hp-parisc2-cc target, wrong bignum code is generated. 77This is due to the SIXTY_FOUR_BIT build being compiled with the +O3 78aggressive optimization. 79The problem manifests itself by the BN_kronecker test hanging in an 80endless loop. Reason: the BN_kronecker test calls BN_generate_prime() 81which itself hangs. The reason could be tracked down to the bn_mul_comba8() 82function in bn_asm.c. At some occasions the higher 32bit value of r[7] 83is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed, 84as no debugger support possible at +O3 and additional fprintf()'s 85introduced fixed the bug, therefore it is most likely a bug in the 86optimizer. 87The bug was found in the BN_kronecker test but may also lead to 88failures in other parts of the code. 89(See Ticket #426.) 90 91Workaround: modify the target to +O2 when building with no-asm. 92 93* Poor support for AIX shared builds. 94 95do_aix-shared rule is not flexible enough to parameterize through a 96config-line. './Configure aix43-cc shared' is working, but not 97'./Configure aix64-gcc shared'. In latter case make fails to create shared 98libraries. It's possible to build 64-bit shared libraries by running 99'env OBJECT_MODE=64 make', but we need more elegant solution. Preferably one 100supporting even gcc shared builds. See RT#463 for background information. 101 102* Problems building shared libraries on SCO OpenServer Release 5.0.6 103 with gcc 2.95.3 104 105The symptoms appear when running the test suite, more specifically 106test/ectest, with the following result: 107 108OSSL_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 109ectest.c:186: ABORT 110 111The cause of the problem seems to be that isxdigit(), called from 112BN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further 113investigation shows that any of the isxxx() macros return 0 on any 114input. A direct look in the information array that the isxxx() use, 115called __ctype, shows that it contains all zeroes... 116 117Taking a look at the newly created libcrypto.so with nm, one can see 118that the variable __ctype is defined in libcrypto's .bss (which 119explains why it is filled with zeroes): 120 121$ nm -Pg libcrypto.so | grep __ctype 122__ctype B 0011659c 123__ctype2 U 124 125Curiously, __ctype2 is undefined, in spite of being declared in 126/usr/include/ctype.h in exactly the same way as __ctype. 127 128Any information helping to solve this issue would be deeply 129appreciated. 130 131NOTE: building non-shared doesn't come with this problem. 132