]>
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 | ||
cd27b13b 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 | ||
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 | 38 | As long as Apple doesn't fix the problem with ld, this problem building |
df729709 AP |
39 | OpenSSL will remain as is. Well, the problem was addressed in 0.9.8f by |
40 | passing -Wl,-search_paths_first, but it's unknown if the flag was | |
41 | supported from the initial MacOS X release. | |
80e1495b | 42 | |
e74e9c48 RL |
43 | |
44 | * Parallell make leads to errors | |
45 | ||
46 | While running tests, running a parallell make is a bad idea. Many test | |
47 | scripts use the same name for output and input files, which means different | |
48 | will interfere with each other and lead to test failure. | |
49 | ||
8f4e661f | 50 | The solution is simple for now: don't run parallel make when testing. |
ff3345cb RL |
51 | |
52 | ||
db6b4e37 | 53 | * Bugs in gcc triggered |
ff3345cb | 54 | |
db6b4e37 AP |
55 | - According to a problem report, there are bugs in gcc 3.0 that are |
56 | triggered by some of the code in OpenSSL, more specifically in | |
57 | PEM_get_EVP_CIPHER_INFO(). The triggering code is the following: | |
ff3345cb RL |
58 | |
59 | header+=11; | |
60 | if (*header != '4') return(0); header++; | |
61 | if (*header != ',') return(0); header++; | |
62 | ||
db6b4e37 AP |
63 | What happens is that gcc might optimize a little too agressively, and |
64 | you end up with an extra incrementation when *header != '4'. | |
ff3345cb | 65 | |
db6b4e37 AP |
66 | We recommend that you upgrade gcc to as high a 3.x version as you can. |
67 | ||
68 | - According to multiple problem reports, some of our message digest | |
69 | implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64 | |
70 | and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while | |
71 | latter - SHA one. | |
72 | ||
73 | The recomendation is to upgrade your compiler. This naturally applies to | |
74 | other similar cases. | |
75 | ||
76 | - There is a subtle Solaris x86-specific gcc run-time environment bug, which | |
77 | "falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug | |
78 | manifests itself as Segmentation Fault upon early application start-up. | |
79 | The problem can be worked around by patching the environment according to | |
80 | http://www.openssl.org/~appro/values.c. | |
0a2407a8 AP |
81 | |
82 | * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler. | |
83 | ||
84 | As subject suggests SHA-1 might perform poorly (4 times slower) | |
85 | if compiled with WorkShop 6 compiler and -xarch=v9. The cause for | |
86 | this seems to be the fact that compiler emits multiplication to | |
87 | perform shift operations:-( To work the problem around configure | |
88 | with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'. | |
52e5e5c2 LJ |
89 | |
90 | * Problems with hp-parisc2-cc target when used with "no-asm" flag | |
91 | ||
92 | When using the hp-parisc2-cc target, wrong bignum code is generated. | |
93 | This is due to the SIXTY_FOUR_BIT build being compiled with the +O3 | |
94 | aggressive optimization. | |
95 | The problem manifests itself by the BN_kronecker test hanging in an | |
96 | endless loop. Reason: the BN_kronecker test calls BN_generate_prime() | |
97 | which itself hangs. The reason could be tracked down to the bn_mul_comba8() | |
98 | function in bn_asm.c. At some occasions the higher 32bit value of r[7] | |
99 | is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed, | |
100 | as no debugger support possible at +O3 and additional fprintf()'s | |
101 | introduced fixed the bug, therefore it is most likely a bug in the | |
102 | optimizer. | |
103 | The bug was found in the BN_kronecker test but may also lead to | |
104 | failures in other parts of the code. | |
105 | (See Ticket #426.) | |
106 | ||
107 | Workaround: modify the target to +O2 when building with no-asm. | |
04da4558 | 108 | |
5924c216 RL |
109 | * Problems building shared libraries on SCO OpenServer Release 5.0.6 |
110 | with gcc 2.95.3 | |
111 | ||
112 | The symptoms appear when running the test suite, more specifically | |
113 | test/ectest, with the following result: | |
114 | ||
115 | 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 | |
116 | ectest.c:186: ABORT | |
117 | ||
118 | The cause of the problem seems to be that isxdigit(), called from | |
119 | BN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further | |
120 | investigation shows that any of the isxxx() macros return 0 on any | |
121 | input. A direct look in the information array that the isxxx() use, | |
122 | called __ctype, shows that it contains all zeroes... | |
123 | ||
124 | Taking a look at the newly created libcrypto.so with nm, one can see | |
125 | that the variable __ctype is defined in libcrypto's .bss (which | |
126 | explains why it is filled with zeroes): | |
127 | ||
128 | $ nm -Pg libcrypto.so | grep __ctype | |
129 | __ctype B 0011659c | |
130 | __ctype2 U | |
131 | ||
132 | Curiously, __ctype2 is undefined, in spite of being declared in | |
133 | /usr/include/ctype.h in exactly the same way as __ctype. | |
134 | ||
135 | Any information helping to solve this issue would be deeply | |
136 | appreciated. | |
137 | ||
138 | NOTE: building non-shared doesn't come with this problem. | |
ce074604 AP |
139 | |
140 | * ULTRIX build fails with shell errors, such as "bad substitution" | |
141 | and "test: argument expected" | |
142 | ||
143 | The problem is caused by ULTRIX /bin/sh supporting only original | |
144 | Bourne shell syntax/semantics, and the trouble is that the vast | |
145 | majority is so accustomed to more modern syntax, that very few | |
146 | people [if any] would recognize the ancient syntax even as valid. | |
147 | This inevitably results in non-trivial scripts breaking on ULTRIX, | |
148 | and OpenSSL isn't an exclusion. Fortunately there is workaround, | |
149 | hire /bin/ksh to do the job /bin/sh fails to do. | |
150 | ||
151 | 1. Trick make(1) to use /bin/ksh by setting up following environ- | |
152 | ment variables *prior* you execute ./Configure and make: | |
153 | ||
154 | PROG_ENV=POSIX | |
155 | MAKESHELL=/bin/ksh | |
156 | export PROG_ENV MAKESHELL | |
157 | ||
158 | or if your shell is csh-compatible: | |
159 | ||
160 | setenv PROG_ENV POSIX | |
161 | setenv MAKESHELL /bin/ksh | |
162 | ||
163 | 2. Trick /bin/sh to use alternative expression evaluator. Create | |
164 | following 'test' script for example in /tmp: | |
165 | ||
166 | #!/bin/ksh | |
167 | ${0##*/} "$@" | |
168 | ||
169 | Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend* | |
170 | your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter- | |
171 | natively just replace system /bin/test and /bin/[ with the | |
172 | above script. | |
55d03c31 AP |
173 | |
174 | * hpux64-ia64-cc fails blowfish test. | |
175 | ||
176 | Compiler bug, presumably at particular patch level. It should be noted | |
177 | that same compiler generates correct 32-bit code, a.k.a. hpux-ia64-cc | |
178 | target. Drop optimization level to +O2 when compiling 64-bit bf_skey.o. | |
c8310124 RL |
179 | |
180 | * no-engines generates errors. | |
181 | ||
182 | Unfortunately, the 'no-engines' configuration option currently doesn't | |
183 | work properly. Use 'no-hw' and you'll will at least get no hardware | |
184 | support. We'll see how we fix that on OpenSSL versions past 0.9.8. | |
0293371a AP |
185 | |
186 | * 'make test' fails in BN_sqr [commonly with "error 139" denoting SIGSEGV] | |
187 | if elder GNU binutils were deployed to link shared libcrypto.so. | |
188 | ||
189 | As subject suggests the failure is caused by a bug in elder binutils, | |
190 | either as or ld, and was observed on FreeBSD and Linux. There are two | |
191 | options. First is naturally to upgrade binutils, the second one - to | |
192 | reconfigure with additional no-sse2 [or 386] option passed to ./config. | |
3001a770 AP |
193 | |
194 | * If configured with ./config no-dso, toolkit still gets linked with -ldl, | |
195 | which most notably poses a problem when linking with dietlibc. | |
196 | ||
197 | We don't have framework to associate -ldl with no-dso, therefore the only | |
198 | way is to edit Makefile right after ./config no-dso and remove -ldl from | |
199 | EX_LIBS line. | |
cb726fe8 AP |
200 | |
201 | * hpux-parisc2-cc no-asm build fails with SEGV in ECDSA/DH. | |
202 | ||
203 | Compiler bug, presumably at particular patch level. Remaining | |
204 | hpux*-parisc*-cc configurations can be affected too. Drop optimization | |
205 | level to +O2 when compiling bn_nist.o. | |
206 | ||
207 | * solaris64-sparcv9-cc link failure | |
208 | ||
209 | Solaris 8 ar can fail to maintain symbol table in .a, which results in | |
210 | link failures. Apply 109147-09 or later or modify Makefile generated | |
211 | by ./Configure solaris64-sparcv9-cc and replace RANLIB assignment with | |
212 | ||
213 | RANLIB= /usr/ccs/bin/ar rs |