mirror of https://github.com/openssl/openssl.git
123 lines
4.8 KiB
Plaintext
123 lines
4.8 KiB
Plaintext
* 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.
|
|
|
|
* 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.
|