1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
NOTE: The problem described here only applies when OpenSSL isn't built
with shared library support (i.e. without the "shared" configuration
option). If you build with shared library support, you will have no
problems as long as you set up DYLD_LIBRARY_PATH properly at all times.
This is really a misfeature in ld, which seems to look for .dylib libraries
along the whole library path before it bothers looking for .a libraries. This
means that -L switches won't matter unless OpenSSL is built with shared
library support.
The workaround may be to change the following lines in apps/Makefile and
test/Makefile:
LIBCRYPTO=-L.. -lcrypto
LIBSSL=-L.. -lssl
to:
LIBCRYPTO=../libcrypto.a
LIBSSL=../libssl.a
It's possible that something similar is needed for shared library support
as well. That hasn't been well tested yet.
Another solution that many seem to recommend is to move the libraries
/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
directory, build and install OpenSSL and anything that depends on your
build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
original places. Note that the version numbers on those two libraries
may differ on your machine.
As long as Apple doesn't fix the problem with ld, this problem building
OpenSSL will remain as is.
* Parallell make leads to errors
While running tests, running a parallell make is a bad idea. Many test
scripts use the same name for output and input files, which means different
will interfere with each other and lead to test failure.
The solution is simple for now: don't run parallell make when testing.
* Bugs in gcc triggered
- According to a problem report, there are bugs in gcc 3.0 that are
triggered by some of the code in OpenSSL, more specifically in
PEM_get_EVP_CIPHER_INFO(). The triggering code is the following:
header+=11;
if (*header != '4') return(0); header++;
if (*header != ',') return(0); header++;
What happens is that gcc might optimize a little too agressively, and
you end up with an extra incrementation when *header != '4'.
We recommend that you upgrade gcc to as high a 3.x version as you can.
- According to multiple problem reports, some of our message digest
implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64
and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while
latter - SHA one.
The recomendation is to upgrade your compiler. This naturally applies to
other similar cases.
- There is a subtle Solaris x86-specific gcc run-time environment bug, which
"falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug
manifests itself as Segmentation Fault upon early application start-up.
The problem can be worked around by patching the environment according to
http://www.openssl.org/~appro/values.c.
* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
As subject suggests SHA-1 might perform poorly (4 times slower)
if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
this seems to be the fact that compiler emits multiplication to
perform shift operations:-( To work the problem around configure
with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
* Problems with hp-parisc2-cc target when used with "no-asm" flag
When using the hp-parisc2-cc target, wrong bignum code is generated.
This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
aggressive optimization.
The problem manifests itself by the BN_kronecker test hanging in an
endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
which itself hangs. The reason could be tracked down to the bn_mul_comba8()
function in bn_asm.c. At some occasions the higher 32bit value of r[7]
is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
as no debugger support possible at +O3 and additional fprintf()'s
introduced fixed the bug, therefore it is most likely a bug in the
optimizer.
The bug was found in the BN_kronecker test but may also lead to
failures in other parts of the code.
(See Ticket #426.)
Workaround: modify the target to +O2 when building with no-asm.
* Problems building shared libraries on SCO OpenServer Release 5.0.6
with gcc 2.95.3
The symptoms appear when running the test suite, more specifically
test/ectest, with the following result:
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
ectest.c:186: ABORT
The cause of the problem seems to be that isxdigit(), called from
BN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further
investigation shows that any of the isxxx() macros return 0 on any
input. A direct look in the information array that the isxxx() use,
called __ctype, shows that it contains all zeroes...
Taking a look at the newly created libcrypto.so with nm, one can see
that the variable __ctype is defined in libcrypto's .bss (which
explains why it is filled with zeroes):
$ nm -Pg libcrypto.so | grep __ctype
__ctype B 0011659c
__ctype2 U
Curiously, __ctype2 is undefined, in spite of being declared in
/usr/include/ctype.h in exactly the same way as __ctype.
Any information helping to solve this issue would be deeply
appreciated.
NOTE: building non-shared doesn't come with this problem.
* ULTRIX build fails with shell errors, such as "bad substitution"
and "test: argument expected"
The problem is caused by ULTRIX /bin/sh supporting only original
Bourne shell syntax/semantics, and the trouble is that the vast
majority is so accustomed to more modern syntax, that very few
people [if any] would recognize the ancient syntax even as valid.
This inevitably results in non-trivial scripts breaking on ULTRIX,
and OpenSSL isn't an exclusion. Fortunately there is workaround,
hire /bin/ksh to do the job /bin/sh fails to do.
1. Trick make(1) to use /bin/ksh by setting up following environ-
ment variables *prior* you execute ./Configure and make:
PROG_ENV=POSIX
MAKESHELL=/bin/ksh
export PROG_ENV MAKESHELL
or if your shell is csh-compatible:
setenv PROG_ENV POSIX
setenv MAKESHELL /bin/ksh
2. Trick /bin/sh to use alternative expression evaluator. Create
following 'test' script for example in /tmp:
#!/bin/ksh
${0##*/} "$@"
Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend*
your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter-
natively just replace system /bin/test and /bin/[ with the
above script.
|
