Update build for OpenSSL-1.0.0a.
[dragonfly.git] / crypto / openssl / PROBLEMS
CommitLineData
56276539
SS
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
10This is really a misfeature in ld, which seems to look for .dylib libraries
11along the whole library path before it bothers looking for .a libraries. This
12means that -L switches won't matter unless OpenSSL is built with shared
13library support.
14
15The workaround may be to change the following lines in apps/Makefile and
16test/Makefile:
17
18 LIBCRYPTO=-L.. -lcrypto
19 LIBSSL=-L.. -lssl
20
21to:
22
23 LIBCRYPTO=../libcrypto.a
24 LIBSSL=../libssl.a
25
26It's possible that something similar is needed for shared library support
27as well. That hasn't been well tested yet.
28
29
30Another 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
32directory, build and install OpenSSL and anything that depends on your
33build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
34original places. Note that the version numbers on those two libraries
35may differ on your machine.
36
37
38As long as Apple doesn't fix the problem with ld, this problem building
39OpenSSL will remain as is.
40
41
42* Parallell make leads to errors
43
44While running tests, running a parallell make is a bad idea. Many test
45scripts use the same name for output and input files, which means different
46will interfere with each other and lead to test failure.
47
48The solution is simple for now: don't run parallell make when testing.
49
50
51* Bugs in gcc 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- 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.
79
80* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
81
82As subject suggests SHA-1 might perform poorly (4 times slower)
83if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
84this seems to be the fact that compiler emits multiplication to
85perform shift operations:-( To work the problem around configure
86with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
87
88* Problems with hp-parisc2-cc target when used with "no-asm" flag
89
90When using the hp-parisc2-cc target, wrong bignum code is generated.
91This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
92aggressive optimization.
93The problem manifests itself by the BN_kronecker test hanging in an
94endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
95which itself hangs. The reason could be tracked down to the bn_mul_comba8()
96function in bn_asm.c. At some occasions the higher 32bit value of r[7]
97is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
98as no debugger support possible at +O3 and additional fprintf()'s
99introduced fixed the bug, therefore it is most likely a bug in the
100optimizer.
101The bug was found in the BN_kronecker test but may also lead to
102failures in other parts of the code.
103(See Ticket #426.)
104
105Workaround: modify the target to +O2 when building with no-asm.
106
107* Problems building shared libraries on SCO OpenServer Release 5.0.6
108 with gcc 2.95.3
109
110The symptoms appear when running the test suite, more specifically
111test/ectest, with the following result:
112
113OSSL_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
114ectest.c:186: ABORT
115
116The cause of the problem seems to be that isxdigit(), called from
117BN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further
118investigation shows that any of the isxxx() macros return 0 on any
119input. A direct look in the information array that the isxxx() use,
120called __ctype, shows that it contains all zeroes...
121
122Taking a look at the newly created libcrypto.so with nm, one can see
123that the variable __ctype is defined in libcrypto's .bss (which
124explains why it is filled with zeroes):
125
126$ nm -Pg libcrypto.so | grep __ctype
127__ctype B 0011659c
128__ctype2 U
129
130Curiously, __ctype2 is undefined, in spite of being declared in
131/usr/include/ctype.h in exactly the same way as __ctype.
132
133Any information helping to solve this issue would be deeply
134appreciated.
135
136NOTE: building non-shared doesn't come with this problem.
137
138* ULTRIX build fails with shell errors, such as "bad substitution"
139 and "test: argument expected"
140
141The problem is caused by ULTRIX /bin/sh supporting only original
142Bourne shell syntax/semantics, and the trouble is that the vast
143majority is so accustomed to more modern syntax, that very few
144people [if any] would recognize the ancient syntax even as valid.
145This inevitably results in non-trivial scripts breaking on ULTRIX,
146and OpenSSL isn't an exclusion. Fortunately there is workaround,
147hire /bin/ksh to do the job /bin/sh fails to do.
148
1491. 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
1612. 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.
171
172* hpux64-ia64-cc fails blowfish test.
173
174Compiler bug, presumably at particular patch level. It should be noted
175that same compiler generates correct 32-bit code, a.k.a. hpux-ia64-cc
176target. Drop optimization level to +O2 when compiling 64-bit bf_skey.o.
177
178* no-engines generates errors.
179
180Unfortunately, the 'no-engines' configuration option currently doesn't
181work properly. Use 'no-hw' and you'll will at least get no hardware
182support. We'll see how we fix that on OpenSSL versions past 0.9.8.
5bd86ce5
SS
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
187As subject suggests the failure is caused by a bug in elder binutils,
188either as or ld, and was observed on FreeBSD and Linux. There are two
189options. First is naturally to upgrade binutils, the second one - to
190reconfigure with additional no-sse2 [or 386] option passed to ./config.
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
195We don't have framework to associate -ldl with no-dso, therefore the only
196way is to edit Makefile right after ./config no-dso and remove -ldl from
197EX_LIBS line.