generic-library/openssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

./PROBLEMS update from HEAD.

Browse Source
This commit is contained in:
Andy Polyakov 2005-06-05 18:09:24 +00:00
parent 9f32d49de9
commit 6d0e43d555
1 changed files with 57 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
PROBLEMS
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
library support.
The workaround may be to change the following lines in apps/Makefile and
test/Makefile:
The workaround may be to change the following lines in apps/Makefile.ssl and
test/Makefile.ssl:
LIBCRYPTO=-L.. -lcrypto
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.
* Bugs in gcc 3.0 triggered
* Bugs in gcc 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:
- 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'.
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.
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.
@ -120,3 +134,37 @@ Any information helping to solve this issue would be deeply
appreciated.
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.