PROBLEMS revision 109998
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'. 73