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