]>
Commit | Line | Data |
---|---|---|
80e1495b | 1 | * System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X. |
9f1c3d73 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 | ||
0b62d2f4 AP |
15 | The workaround may be to change the following lines in apps/Makefile and |
16 | test/Makefile: | |
80e1495b RL |
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 | ||
ec27c2ac 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 | ||
716c9449 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. | |
6b27ae1d RL |
49 | |
50 | ||
6d0e43d5 | 51 | * Bugs in gcc triggered |
6b27ae1d | 52 | |
6d0e43d5 AP |
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: | |
6b27ae1d RL |
56 | |
57 | header+=11; | |
58 | if (*header != '4') return(0); header++; | |
59 | if (*header != ',') return(0); header++; | |
60 | ||
6d0e43d5 AP |
61 | What happens is that gcc might optimize a little too agressively, and |
62 | you end up with an extra incrementation when *header != '4'. | |
6b27ae1d | 63 | |
6d0e43d5 AP |
64 | We recommend that you upgrade gcc to as high a 3.x version as you can. |
65 | ||
66 | - According to multiple problem reports, some of our message digest | |
67 | implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64 | |
68 | and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while | |
69 | latter - SHA one. | |
70 | ||
71 | The recomendation is to upgrade your compiler. This naturally applies to | |
72 | other similar cases. | |
73 | ||
0c780463 AP |
74 | * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler. |
75 | ||
76 | As subject suggests SHA-1 might perform poorly (4 times slower) | |
77 | if compiled with WorkShop 6 compiler and -xarch=v9. The cause for | |
78 | this seems to be the fact that compiler emits multiplication to | |
79 | perform shift operations:-( To work the problem around configure | |
80 | with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'. | |
96f2552c LJ |
81 | |
82 | * Problems with hp-parisc2-cc target when used with "no-asm" flag | |
83 | ||
84 | When using the hp-parisc2-cc target, wrong bignum code is generated. | |
85 | This is due to the SIXTY_FOUR_BIT build being compiled with the +O3 | |
86 | aggressive optimization. | |
87 | The problem manifests itself by the BN_kronecker test hanging in an | |
88 | endless loop. Reason: the BN_kronecker test calls BN_generate_prime() | |
89 | which itself hangs. The reason could be tracked down to the bn_mul_comba8() | |
90 | function in bn_asm.c. At some occasions the higher 32bit value of r[7] | |
91 | is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed, | |
92 | as no debugger support possible at +O3 and additional fprintf()'s | |
93 | introduced fixed the bug, therefore it is most likely a bug in the | |
94 | optimizer. | |
95 | The bug was found in the BN_kronecker test but may also lead to | |
96 | failures in other parts of the code. | |
97 | (See Ticket #426.) | |
98 | ||
99 | Workaround: modify the target to +O2 when building with no-asm. | |
118204f9 | 100 | |
74b0c41e RL |
101 | * Problems building shared libraries on SCO OpenServer Release 5.0.6 |
102 | with gcc 2.95.3 | |
103 | ||
104 | The symptoms appear when running the test suite, more specifically | |
105 | test/ectest, with the following result: | |
106 | ||
107 | 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 | |
108 | ectest.c:186: ABORT | |
109 | ||
110 | The cause of the problem seems to be that isxdigit(), called from | |
111 | BN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further | |
112 | investigation shows that any of the isxxx() macros return 0 on any | |
113 | input. A direct look in the information array that the isxxx() use, | |
114 | called __ctype, shows that it contains all zeroes... | |
115 | ||
116 | Taking a look at the newly created libcrypto.so with nm, one can see | |
117 | that the variable __ctype is defined in libcrypto's .bss (which | |
118 | explains why it is filled with zeroes): | |
119 | ||
120 | $ nm -Pg libcrypto.so | grep __ctype | |
121 | __ctype B 0011659c | |
122 | __ctype2 U | |
123 | ||
124 | Curiously, __ctype2 is undefined, in spite of being declared in | |
125 | /usr/include/ctype.h in exactly the same way as __ctype. | |
126 | ||
127 | Any information helping to solve this issue would be deeply | |
128 | appreciated. | |
129 | ||
130 | NOTE: building non-shared doesn't come with this problem. | |
6d0e43d5 AP |
131 | |
132 | * ULTRIX build fails with shell errors, such as "bad substitution" | |
133 | and "test: argument expected" | |
134 | ||
135 | The problem is caused by ULTRIX /bin/sh supporting only original | |
136 | Bourne shell syntax/semantics, and the trouble is that the vast | |
137 | majority is so accustomed to more modern syntax, that very few | |
138 | people [if any] would recognize the ancient syntax even as valid. | |
139 | This inevitably results in non-trivial scripts breaking on ULTRIX, | |
140 | and OpenSSL isn't an exclusion. Fortunately there is workaround, | |
141 | hire /bin/ksh to do the job /bin/sh fails to do. | |
142 | ||
143 | 1. Trick make(1) to use /bin/ksh by setting up following environ- | |
144 | ment variables *prior* you execute ./Configure and make: | |
145 | ||
146 | PROG_ENV=POSIX | |
147 | MAKESHELL=/bin/ksh | |
148 | export PROG_ENV MAKESHELL | |
149 | ||
150 | or if your shell is csh-compatible: | |
151 | ||
152 | setenv PROG_ENV POSIX | |
153 | setenv MAKESHELL /bin/ksh | |
154 | ||
155 | 2. Trick /bin/sh to use alternative expression evaluator. Create | |
156 | following 'test' script for example in /tmp: | |
157 | ||
158 | #!/bin/ksh | |
159 | ${0##*/} "$@" | |
160 | ||
161 | Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend* | |
162 | your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter- | |
163 | natively just replace system /bin/test and /bin/[ with the | |
164 | above script. |