PROBLEMS revision 111147
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 15100936SnectarThe workaround may be to change the following lines in apps/Makefile.ssl and 16100936Snectartest/Makefile.ssl: 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 39100936SnectarOpenSSL will remain as is. 40100936Snectar 41101613Snectar 42101613Snectar* Parallell make leads to errors 43101613Snectar 44101613SnectarWhile running tests, running a parallell make is a bad idea. Many test 45101613Snectarscripts use the same name for output and input files, which means different 46101613Snectarwill interfere with each other and lead to test failure. 47101613Snectar 48101613SnectarThe solution is simple for now: don't run parallell make when testing. 49109998Smarkm 50109998Smarkm 51109998Smarkm* Bugs in gcc 3.0 triggered 52109998Smarkm 53109998SmarkmAccording to a problem report, there are bugs in gcc 3.0 that are 54109998Smarkmtriggered by some of the code in OpenSSL, more specifically in 55109998SmarkmPEM_get_EVP_CIPHER_INFO(). The triggering code is the following: 56109998Smarkm 57109998Smarkm header+=11; 58109998Smarkm if (*header != '4') return(0); header++; 59109998Smarkm if (*header != ',') return(0); header++; 60109998Smarkm 61109998SmarkmWhat happens is that gcc might optimize a little too agressively, and 62109998Smarkmyou end up with an extra incrementation when *header != '4'. 63109998Smarkm 64109998SmarkmWe recommend that you upgrade gcc to as high a 3.x version as you can. 65109998Smarkm 66109998Smarkm* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler. 67109998Smarkm 68109998SmarkmAs subject suggests SHA-1 might perform poorly (4 times slower) 69109998Smarkmif compiled with WorkShop 6 compiler and -xarch=v9. The cause for 70109998Smarkmthis seems to be the fact that compiler emits multiplication to 71109998Smarkmperform shift operations:-( To work the problem around configure 72109998Smarkmwith './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'. 73111147Snectar 74111147Snectar* Problems with hp-parisc2-cc target when used with "no-asm" flag 75111147Snectar 76111147SnectarWhen using the hp-parisc2-cc target, wrong bignum code is generated. 77111147SnectarThis is due to the SIXTY_FOUR_BIT build being compiled with the +O3 78111147Snectaraggressive optimization. 79111147SnectarThe problem manifests itself by the BN_kronecker test hanging in an 80111147Snectarendless loop. Reason: the BN_kronecker test calls BN_generate_prime() 81111147Snectarwhich itself hangs. The reason could be tracked down to the bn_mul_comba8() 82111147Snectarfunction in bn_asm.c. At some occasions the higher 32bit value of r[7] 83111147Snectaris off by 1 (meaning: calculated=shouldbe+1). Further analysis failed, 84111147Snectaras no debugger support possible at +O3 and additional fprintf()'s 85111147Snectarintroduced fixed the bug, therefore it is most likely a bug in the 86111147Snectaroptimizer. 87111147SnectarThe bug was found in the BN_kronecker test but may also lead to 88111147Snectarfailures in other parts of the code. 89111147Snectar(See Ticket #426.) 90111147Snectar 91111147SnectarWorkaround: modify the target to +O2 when building with no-asm. 92111147Snectar 93111147Snectar* Poor support for AIX shared builds. 94111147Snectar 95111147Snectardo_aix-shared rule is not flexible enough to parameterize through a 96111147Snectarconfig-line. './Configure aix43-cc shared' is working, but not 97111147Snectar'./Configure aix64-gcc shared'. In latter case make fails to create shared 98111147Snectarlibraries. It's possible to build 64-bit shared libraries by running 99111147Snectar'env OBJECT_MODE=64 make', but we need more elegant solution. Preferably one 100111147Snectarsupporting even gcc shared builds. See RT#463 for background information. 101