[18441] | 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 | |
---|
| 10 | This is really a misfeature in ld, which seems to look for .dylib libraries |
---|
| 11 | along the whole library path before it bothers looking for .a libraries. This |
---|
| 12 | means that -L switches won't matter unless OpenSSL is built with shared |
---|
| 13 | library support. |
---|
| 14 | |
---|
| 15 | The workaround may be to change the following lines in apps/Makefile.ssl and |
---|
| 16 | test/Makefile.ssl: |
---|
| 17 | |
---|
| 18 | LIBCRYPTO=-L.. -lcrypto |
---|
| 19 | LIBSSL=-L.. -lssl |
---|
| 20 | |
---|
| 21 | to: |
---|
| 22 | |
---|
| 23 | LIBCRYPTO=../libcrypto.a |
---|
| 24 | LIBSSL=../libssl.a |
---|
| 25 | |
---|
| 26 | It's possible that something similar is needed for shared library support |
---|
| 27 | as well. That hasn't been well tested yet. |
---|
| 28 | |
---|
| 29 | |
---|
| 30 | Another 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 |
---|
| 32 | directory, build and install OpenSSL and anything that depends on your |
---|
| 33 | build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their |
---|
| 34 | original places. Note that the version numbers on those two libraries |
---|
| 35 | may differ on your machine. |
---|
| 36 | |
---|
| 37 | |
---|
| 38 | As long as Apple doesn't fix the problem with ld, this problem building |
---|
| 39 | OpenSSL will remain as is. |
---|
| 40 | |
---|
| 41 | |
---|
| 42 | * Parallell make leads to errors |
---|
| 43 | |
---|
| 44 | While running tests, running a parallell make is a bad idea. Many test |
---|
| 45 | scripts use the same name for output and input files, which means different |
---|
| 46 | will interfere with each other and lead to test failure. |
---|
| 47 | |
---|
| 48 | The solution is simple for now: don't run parallell make when testing. |
---|
| 49 | |
---|
| 50 | |
---|
| 51 | * Bugs in gcc 3.0 triggered |
---|
| 52 | |
---|
| 53 | According to a problem report, there are bugs in gcc 3.0 that are |
---|
| 54 | triggered by some of the code in OpenSSL, more specifically in |
---|
| 55 | PEM_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 | |
---|
| 61 | What happens is that gcc might optimize a little too agressively, and |
---|
| 62 | you end up with an extra incrementation when *header != '4'. |
---|
| 63 | |
---|
| 64 | We 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 | |
---|
| 68 | As subject suggests SHA-1 might perform poorly (4 times slower) |
---|
| 69 | if compiled with WorkShop 6 compiler and -xarch=v9. The cause for |
---|
| 70 | this seems to be the fact that compiler emits multiplication to |
---|
| 71 | perform shift operations:-( To work the problem around configure |
---|
| 72 | with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'. |
---|