]>
Commit | Line | Data |
---|---|---|
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'. | |
73 | ||
74 | * Problems with hp-parisc2-cc target when used with "no-asm" flag | |
75 | ||
76 | When using the hp-parisc2-cc target, wrong bignum code is generated. | |
77 | This is due to the SIXTY_FOUR_BIT build being compiled with the +O3 | |
78 | aggressive optimization. | |
79 | The problem manifests itself by the BN_kronecker test hanging in an | |
80 | endless loop. Reason: the BN_kronecker test calls BN_generate_prime() | |
81 | which itself hangs. The reason could be tracked down to the bn_mul_comba8() | |
82 | function in bn_asm.c. At some occasions the higher 32bit value of r[7] | |
83 | is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed, | |
84 | as no debugger support possible at +O3 and additional fprintf()'s | |
85 | introduced fixed the bug, therefore it is most likely a bug in the | |
86 | optimizer. | |
87 | The bug was found in the BN_kronecker test but may also lead to | |
88 | failures in other parts of the code. | |
89 | (See Ticket #426.) | |
90 | ||
91 | Workaround: modify the target to +O2 when building with no-asm. | |
92 | ||
93 | * Poor support for AIX shared builds. | |
94 | ||
95 | do_aix-shared rule is not flexible enough to parameterize through a | |
96 | config-line. './Configure aix43-cc shared' is working, but not | |
97 | './Configure aix64-gcc shared'. In latter case make fails to create shared | |
98 | libraries. It's possible to build 64-bit shared libraries by running | |
99 | 'env OBJECT_MODE=64 make', but we need more elegant solution. Preferably one | |
100 | supporting even gcc shared builds. See RT#463 for background information. |