is used, even if the user has GNU ld earlier in his $PATH.

The linux-shared method is actually gcc-specific, so call it
gnu-shared as well.

seems like some Unixen (SCO) have opinions about too many -L.

abort with errors if no name is defined for some object, which was the
case for 'pilotAttributeType 27'.

Also avoid this very situation by assigning the name
'pilotAttributeType27'.

Add EC vaporware: change relevant Makefiles and add some empty source
files.

"make update".

and make all files the depend on it include it without prefixing it
with openssl/.

This means that all Makefiles will have $(TOP) as one of the include
directories.

sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.

I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.

"make tests"

First tentative impementation of Kerberos 5 cryptos and keys for SSL/TLS.  Implemented by Vern Staats <staatsvr@asc.hpc.mil>, further hacked and distributed by Jeffrey Altman <jaltnab@columbia.edu>

For performance reasons, it is also recommended to make the (mmap'ed)
shared library 'read-only'.
-> New permissions for installed shared libraries = 555

This doesn't hurt anybody, provided the installation is performed with
'cp -f' :-)

"-Wl,+s" instead of +s:
* Hardcoded necessary references to -ldld/-ldl into the build rules and
  removed EX_LIBS.

HP-UX records the pathnames of dependent libraries when the shared libs
are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with
"./" not being resolvable when running an application linked against -lssl:
* Build libssl without explicit reference to libcrypto, applications will
  be linked with "-lssl -lcrypto" anyway.

Document these informations in Makefile.org.

individual tests.  I finally got myself to implement it...

away now...

full version number and not just 0.  This should mark the shared
libraries as not backward compatible.  Of course, this should be
changed again when we can guarantee backward binary compatibility.

Submitted by Albert Chin-A-Young <china@thewrittenword.com>

Suggested by Albert Chin-A-Young <china@thewrittenword.com>

At the same time, add VMS support for Rijndael.

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.

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

make update done.

  - 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.

something is going on (and what).

requires that you configure again, but you don't want to reenter all
those configuration arguments again.

MD4 implemented.  Assar Westerlund provided the digest code itself and the test utility, I added the bits to get a EVP interface, the command line utility and the speed test

1. make sure libssl.so becomes dependent on libcrypto.so
2. correct a number of silly bugs in the solaris-shared target, and make
   sure lib*.so also depends on libc.so.

(there's no way to get it through configuration yet).

libraries even if the "shared" configuration option wasn't chosen.

there's support for building under Linux and True64 (using examples
from the programming manuals), including versioning that is currently
the same as OpenSSL versions but should really be a different series.

With this change, it's up to the users to decide if they want shared
libraries as well as the static ones.  This decision now has to be
done at configuration time (well, not really, those who know what they
do can still do it the same way as before).

The OpenSSL programs (openssl and the test programs) are currently
always linked statically, but this may change in the future in a
configurable manner.  The necessary makefile variables to enable this
are in place.

Also note that I have done absolutely nothing about the Windows target
to get something similar.  On the other hand, DLLs are already the
default there, but without versioning, and I've no idea what the
possibilities for such a thing are there...

could be done automagically, much like the numbering in libeay.num and
ssleay.num.  The solution works as follows:

  - New object identifiers are inserted in objects.txt, following the
    syntax given in objects.README.
  - objects.pl is used to process obj_mac.num and create a new
    obj_mac.h.
  - obj_dat.pl is used to create a new obj_dat.h, using the data in
    obj_mac.h.

This is currently kind of a hack, and the perl code in objects.pl
isn't very elegant, but it works as I intended.  The simplest way to
check that it worked correctly is to look in obj_dat.h and check the
array nid_objs and make sure the objects haven't moved around (this is
important!).  Additions are OK, as well as consistent name changes.

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.