Avoid "empty source file" warnings.
[oweals/openssl.git] / PROBLEMS
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
15 The workaround may be to change the following lines in apps/Makefile.ssl and
16 test/Makefile.ssl:
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
39 OpenSSL will remain as is.
40
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.
49
50
51 * Bugs in gcc 3.0 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 * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
67
68 As subject suggests SHA-1 might perform poorly (4 times slower)
69 if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
70 this seems to be the fact that compiler emits multiplication to
71 perform shift operations:-( To work the problem around configure
72 with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
73
74 * Problems with hp-parisc2-cc target when used with "no-asm" flag
75
76 When using the hp-parisc2-cc target, wrong bignum code is generated.
77 This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
78 aggressive optimization.
79 The problem manifests itself by the BN_kronecker test hanging in an
80 endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
81 which itself hangs. The reason could be tracked down to the bn_mul_comba8()
82 function in bn_asm.c. At some occasions the higher 32bit value of r[7]
83 is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
84 as no debugger support possible at +O3 and additional fprintf()'s
85 introduced fixed the bug, therefore it is most likely a bug in the
86 optimizer.
87 The bug was found in the BN_kronecker test but may also lead to
88 failures in other parts of the code.
89 (See Ticket #426.)
90
91 Workaround: modify the target to +O2 when building with no-asm.
92
93 * Poor support for AIX shared builds.
94
95 do_aix-shared rule is not flexible enough to parameterize through a
96 config-line. './Configure aix43-cc shared' is working, but not
97 './Configure aix64-gcc shared'. In latter case make fails to create shared
98 libraries. It's possible to build 64-bit shared libraries by running
99 'env OBJECT_MODE=64 make', but we need more elegant solution. Preferably one
100 supporting even gcc shared builds. See RT#463 for background information.
101
102 * Problems building shared libraries on SCO OpenServer Release 5.0.6
103   with gcc 2.95.3
104
105 The symptoms appear when running the test suite, more specifically
106 test/ectest, with the following result:
107
108 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
109 ectest.c:186: ABORT
110
111 The cause of the problem seems to be that isxdigit(), called from
112 BN_hex2bn(), returns 0 on a perfectly legitimate hex digit.  Further
113 investigation shows that any of the isxxx() macros return 0 on any
114 input.  A direct look in the information array that the isxxx() use,
115 called __ctype, shows that it contains all zeroes...
116
117 Taking a look at the newly created libcrypto.so with nm, one can see
118 that the variable __ctype is defined in libcrypto's .bss (which
119 explains why it is filled with zeroes):
120
121 $ nm -Pg libcrypto.so | grep __ctype
122 __ctype B 0011659c
123 __ctype2 U         
124
125 Curiously, __ctype2 is undefined, in spite of being declared in
126 /usr/include/ctype.h in exactly the same way as __ctype.
127
128 Any information helping to solve this issue would be deeply
129 appreciated.
130
131 NOTE: building non-shared doesn't come with this problem.