diff options
Diffstat (limited to 'crypto/openssl/PROBLEMS')
| -rw-r--r-- | crypto/openssl/PROBLEMS | 100 |
1 files changed, 0 insertions, 100 deletions
diff --git a/crypto/openssl/PROBLEMS b/crypto/openssl/PROBLEMS deleted file mode 100644 index 1a956b54815c..000000000000 --- a/crypto/openssl/PROBLEMS +++ /dev/null @@ -1,100 +0,0 @@ -* 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.ssl and -test/Makefile.ssl: - - 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 3.0 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. - -* 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. - -* Poor support for AIX shared builds. - -do_aix-shared rule is not flexible enough to parameterize through a -config-line. './Configure aix43-cc shared' is working, but not -'./Configure aix64-gcc shared'. In latter case make fails to create shared -libraries. It's possible to build 64-bit shared libraries by running -'env OBJECT_MODE=64 make', but we need more elegant solution. Preferably one -supporting even gcc shared builds. See RT#463 for background information. |