1
by Christoph Martin
Import upstream version 0.9.7d |
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 |
||
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
|
|
12 |
means that -L switches won't matter unless OpenSSL is built with shared |
|
13 |
library support. |
|
14 |
||
1.1.1
by Christoph Martin
Import upstream version 0.9.7e |
15 |
The workaround may be to change the following lines in apps/Makefile and |
16 |
test/Makefile: |
|
1
by Christoph Martin
Import upstream version 0.9.7d |
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 |
||
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 |
||
38 |
As long as Apple doesn't fix the problem with ld, this problem building |
|
1.1.11
by Kurt Roeckx
Import upstream version 1.0.0c |
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. |
|
1
by Christoph Martin
Import upstream version 0.9.7d |
42 |
|
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 |
||
50 |
The solution is simple for now: don't run parallell make when testing. |
|
51 |
||
52 |
||
1.1.2
by Kurt Roeckx
Import upstream version 0.9.8a |
53 |
* Bugs in gcc triggered
|
1
by Christoph Martin
Import upstream version 0.9.7d |
54 |
|
1.1.2
by Kurt Roeckx
Import upstream version 0.9.8a |
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:
|
|
1
by Christoph Martin
Import upstream version 0.9.7d |
58 |
|
59 |
header+=11;
|
|
60 |
if (*header != '4') return(0); header++; |
|
61 |
if (*header != ',') return(0); header++; |
|
62 |
||
1.1.2
by Kurt Roeckx
Import upstream version 0.9.8a |
63 |
What happens is that gcc might optimize a little too agressively, and
|
64 |
you end up with an extra incrementation when *header != '4'. |
|
65 |
||
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.
|
|
1
by Christoph Martin
Import upstream version 0.9.7d |
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'. |
|
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. |
|
108 |
||
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. |
|
1.1.2
by Kurt Roeckx
Import upstream version 0.9.8a |
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.
|
|
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.
|
|
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. |
|
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. |
|
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. |