]>
Commit | Line | Data |
---|---|---|
80e1495b | 1 | * System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X. |
fe5eb670 RL |
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 | ||
80e1495b | 9 | |
0487cb23 RL |
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 | |
80e1495b RL |
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 | ||
ebccb429 RL |
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 | ||
80e1495b RL |
38 | As long as Apple doesn't fix the problem with ld, this problem building |
39 | OpenSSL will remain as is. | |
40 | ||
e74e9c48 RL |
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. | |
ff3345cb RL |
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. | |
0a2407a8 AP |
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'. | |
52e5e5c2 LJ |
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. | |
04da4558 | 92 | |
5924c216 RL |
93 | * Problems building shared libraries on SCO OpenServer Release 5.0.6 |
94 | with gcc 2.95.3 | |
95 | ||
96 | The symptoms appear when running the test suite, more specifically | |
97 | test/ectest, with the following result: | |
98 | ||
99 | OSSL_LIBPATH="`cd ..; pwd`"; LD_LIBRARY_PATH="$OSSL_LIBPATH:$LD_LIBRARY_PATH"; DYLD_LIBRARY_PATH="$OSSL_LIBPATH:$DYLD_LIBRARY_PATH"; SHLIB_PATH="$OSSL_LIBPATH:$SHLIB_PATH"; LIBPATH="$OSSL_LIBPATH:$LIBPATH"; if [ "debug-sco5-gcc" = "Cygwin" ]; then PATH="${LIBPATH}:$PATH"; fi; export LD_LIBRARY_PATH DYLD_LIBRARY_PATH SHLIB_PATH LIBPATH PATH; ./ectest | |
100 | ectest.c:186: ABORT | |
101 | ||
102 | The cause of the problem seems to be that isxdigit(), called from | |
103 | BN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further | |
104 | investigation shows that any of the isxxx() macros return 0 on any | |
105 | input. A direct look in the information array that the isxxx() use, | |
106 | called __ctype, shows that it contains all zeroes... | |
107 | ||
108 | Taking a look at the newly created libcrypto.so with nm, one can see | |
109 | that the variable __ctype is defined in libcrypto's .bss (which | |
110 | explains why it is filled with zeroes): | |
111 | ||
112 | $ nm -Pg libcrypto.so | grep __ctype | |
113 | __ctype B 0011659c | |
114 | __ctype2 U | |
115 | ||
116 | Curiously, __ctype2 is undefined, in spite of being declared in | |
117 | /usr/include/ctype.h in exactly the same way as __ctype. | |
118 | ||
119 | Any information helping to solve this issue would be deeply | |
120 | appreciated. | |
121 | ||
122 | NOTE: building non-shared doesn't come with this problem. |