./PROBLEMS update from HEAD.

This commit is contained in:
Andy Polyakov 2005-06-05 18:09:24 +00:00
parent 9f32d49de9
commit 6d0e43d555

View File

@ -12,8 +12,8 @@ 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 means that -L switches won't matter unless OpenSSL is built with shared
library support. library support.
The workaround may be to change the following lines in apps/Makefile and The workaround may be to change the following lines in apps/Makefile.ssl and
test/Makefile: test/Makefile.ssl:
LIBCRYPTO=-L.. -lcrypto LIBCRYPTO=-L.. -lcrypto
LIBSSL=-L.. -lssl LIBSSL=-L.. -lssl
@ -48,20 +48,34 @@ will interfere with each other and lead to test failure.
The solution is simple for now: don't run parallell make when testing. The solution is simple for now: don't run parallell make when testing.
* Bugs in gcc 3.0 triggered * Bugs in gcc triggered
According to a problem report, there are bugs in gcc 3.0 that are - 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 triggered by some of the code in OpenSSL, more specifically in
PEM_get_EVP_CIPHER_INFO(). The triggering code is the following: PEM_get_EVP_CIPHER_INFO(). The triggering code is the following:
header+=11; header+=11;
if (*header != '4') return(0); header++; if (*header != '4') return(0); header++;
if (*header != ',') return(0); header++; if (*header != ',') return(0); header++;
What happens is that gcc might optimize a little too agressively, and What happens is that gcc might optimize a little too agressively, and
you end up with an extra incrementation when *header != '4'. 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. 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. * solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
@ -120,3 +134,37 @@ Any information helping to solve this issue would be deeply
appreciated. appreciated.
NOTE: building non-shared doesn't come with this problem. 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.