make update done.

to have the full extension information, so residual shared libraries
can be removed so the applications and test programs do not get linked
against them by mistake...

  - Make note of the expected extension for the shared libraries and
    if there is a need for symbolic links from for example libcrypto.so.0
    to libcrypto.so.0.9.7.  There is extended info in Configure for
    that.

  - Make as few rebuilds of the shared libraries as possible.

  - Still avoid linking the OpenSSL programs with the shared libraries.

  - When installing, install the shared libraries separately from the
    static ones.

Actually, it's a feature that it goes looking at environment
variables.  It's just a pity that it's at the cost of the error
checking...  I'll see if I can come up with a better interface for
this.

Submitted by Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE>

returns -1...

Submitted by Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE>

thus the condition '!BIO_sock_init()' doesn't make sense.

so I've regenerated the error numbers and strings for the DSO functions.

to make them...

These are now processed inside DSO_ctrl() itself.

commands are common to all DSO_METHODs, hence handle them at the top.

linux-alpha.

Add support for X509_NAME_print_ex() in req.

Initial code for cutomizable X509 print routines.

SSLeay with Colin Plumb's MD5 implementation instead of his one".

supposed to be defined according to XPG4.2.
Found by Evan <n2xjk@ulster.net> for the MVS platform.

something is going on (and what).

accept/connect functions; those should not change the
read_ahead setting of the SSL structure.

Submitted by: Anders Gertz <gertz@epact.se>

algorithms do not get in...

acceptable, since all that happens if it fails is a library with
an index, which makes linking slower, but still working correctly.

selection macros.