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