(although maybe this static variable should be abolished totally,
it was introduced before RAND_status existed).

ld warns that -Fl "may not be supported in future releases".  We know
that, and are doing things in HP-UX 11 (64bit), so turn off that
warning with +vnocompatwarnings.

Use egrep instead.

RAND_status() hasn't.
Reported by Dale Stimson <dale@accentre.com>.

since NetBSD 1.5.

you should defined _THREAD_SAFE (I found that in an include file, and
that's what everybody tells me) or _THREADSAFE (that's what the gcc
manual says in the FreeBSD-specific section), so I defined both, just
to be safe.

N.B.: This has not been tested at all, that's my next step.

causes MASM to complain and not produce valid debug info.
Hopefully this wont break anything else...

Also fix typo in e_rd.c

pointers at the end of the structure.

by providing a function pointer that is given a name instead of a BIO.
For example, this could be used to load configuration data from an
LDAP server.

NCONF_get_number_e() is defined (_e for "error checking") and is
promoted strongly.  The old NCONF_get_number is kept around for
binary backward compatibility.

Free to OPENSSL_free in the SSL demos.

Submitted by:
Reviewed by:
PR:

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>