| Richard Levitte | 80e1495 | 2002-07-16 10:04:40 +0000 | [diff] [blame] | 1 | * System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X. |
| Richard Levitte | fe5eb67 | 2002-07-17 11:16:22 +0000 | [diff] [blame] | 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 | |
| Richard Levitte | 80e1495 | 2002-07-16 10:04:40 +0000 | [diff] [blame] | 9 | |
| Richard Levitte | 0487cb2 | 2002-07-16 10:20:06 +0000 | [diff] [blame] | 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 |
| Richard Levitte | 80e1495 | 2002-07-16 10:04:40 +0000 | [diff] [blame] | 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 | |
| Richard Levitte | ebccb42 | 2002-07-17 07:48:39 +0000 | [diff] [blame] | 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 | |
| Richard Levitte | 80e1495 | 2002-07-16 10:04:40 +0000 | [diff] [blame] | 38 | As long as Apple doesn't fix the problem with ld, this problem building |
| 39 | OpenSSL will remain as is. |
| 40 | |
| Richard Levitte | e74e9c4 | 2002-08-01 21:34:24 +0000 | [diff] [blame] | 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. |
| Richard Levitte | ff3345c | 2002-12-04 08:24:18 +0000 | [diff] [blame^] | 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. |
