always in the users $PATH...

Suggested by Randolph Bentson <bentson@grieg.holmsjoen.com>

(Still needs to be tested against the original using sample passwords
of different length.)

just converting some spaces to tabs from his fix. :-)

comment out in the previous commit

and for small 'a' also a couple of calls to
BN_mod_mul_montgomery(r, r, r, ...).

applications.  Also, have it and the certificate and key loading
functions take a BIO argument for error output.

addition to the file given through the RANDFILE option or environment
variable.

the 'INSTALL' file, which means that 9 times of 10, the BlowFish
headers won't get installed.  Avoid this in the same way it's done in
crypto/des/Makefile.ssl, where someone apparently has thought of this...

be shared by several applications.

parameter takes precedence over the RANDFILE option in the
configuration file.

into lexical order. Previously it depended on
the order of files in the directory.

This should now mean that all systems will
agree on the order of safestack.h and will
not change it needlessly and avoid massive
needless commits to safestack.h in future.

It wont however avoid this one :-(

  it cope with OpenBSD which doesn't understand "RTLD_NOW".
* Added the dso_scheme config string entry for OpenBSD-x86 to give it
  DSO support.
* 'make update' that has also absorbed some of Steve's mkstack changes
  for the ASN-related macros.

Fixes for Win32 build.

This is mostly a work around for the old VC++ problem
that it treats func() as func(void).

Various prototypes had been added to 'compare' function
pointers that triggered this. This could be fixed by removing
the prototype, adding function pointer casts to every call or
changing the passed function to use the expected arguments.
I mostly did the latter.

The mkdef.pl script was modified to remove the typesafe
functions which no longer exist.

Oh and some functions called OPENSSL_freeLibrary() were
changed back to FreeLibrary(), wonder how that happened :-)

Handle ASN1_SET_OF and PKCS12_STACK_OF using function
casts in the same way as STACK_OF.

Also, make sure empty slots of the dynamic lock stack are used.
Actually, I'm not really sure this is the right thing to do, and may
remove it, with an endlessly growing stack as result...

insecure, so a static lock is added to isolate the sensitive parts.
Also, to avoid one thread freeing a lock that is used by another, a
reference counter is added.

any more.

be needed in some ENGINE code, and might serve elsewhere as well.
Note that it's implemented in such a way that the locking itself is
done through the same CRYPTO_lock function as the static locks.

WARNING: This is currently experimental and untested code (it will get
tested soon, though :-)).

type-specific stack function.  Second, even when we don't build any of
those functions, DECLARE_STACK_OF lines should not find themselves
into $def.

sk_whatever_insert and sk_whatever_set immediately reveals the subtle
difference in parameter order.

Change mkstack.pl so that safestack.h is not rewritten when
nothing has changed.

After some messing around this seems to work but needs
a few more tests. Working out the syntax for sk_set_cmp_func()
(cast it to a function that itself returns a function pointer)
was painful :-(

Needs some testing to see what other compilers think of this
syntax.

Also needs similar stuff for ASN1_SET_OF etc etc.

As far as I understand, it still needs to be compiled on NT...
Contributed by Arne Ansper <arne@ats.cyber.ee>

label. (Reported by Alexei Bakharevski.)

"symbols" including functions (of all prototypes( and variables. Whilst
casting any function type to another violates ANSI C (I believe), it is
a necessary evil in shared-library APIs. However, it is quite
conceivable that functions in general and data symbols could very well
be represented differently to each other on some systems, as Bodo said;

> Since the function/object distinction is a lot more likely to be
> important on real-life platforms supporting DSO *and* it can be quite
> easily done *and* it will silence compilers that don't like
> assignments from void pointers to function pointer variables, why
> not do it?

I agree. So this change splits the "dso_bind" handler in DSO_METHOD
into "dso_bind_var" and "dso_bind_func". Similarly the exported
function DSO_bind() has been split in two. I've also put together
changes for the various DSO_METHOD implementations, but so far only
DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been
a bit strange so I've taken the opportunity to change its shape (in
both variations).

Also, the README has been updated - particularly with a note about
using customised native name-translation for shared libraries (and that
you can't do it yet).

Reported by Robert Eiglmaier <robert.eiglmaier@ixos.de>