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. |
---|