| 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'. |
|---|
