Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Signed-off-by: NRich Salz <rsalz@akamai.com>
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Reviewed-by: NStephen Henson <steve@openssl.org>

Reviewed-by: NStephen Henson <steve@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Especially since after the #ifdef cleanups this is not useful.
Reviewed-by: NMatt Caswell <matt@openssl.org>

Rather than making include/openssl/foo.h a symlink to
crypto/foo/foo.h, this change moves the file to include/openssl/foo.h
once and for all.

Likewise, move crypto/foo/footest.c to test/footest.c, instead of
symlinking it there.
Originally-by: NGeoff Thorpe <geoff@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

The FAQ says this:

    After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter
    releases (e.g. 1.0.1a) can only contain bug and security fixes and no
    new features. Minor releases change the last number (e.g. 1.0.2) and
    can contain new features that retain binary compatibility. Changes to
    the middle number are considered major releases and neither source nor
    binary compatibility is guaranteed.

With such a scheme (and with the thinking that it's nice if the shared
library version stays on track with the OpenSSL version), it's rather
futile to keep the minor release number in the shared library version.
The deed already done with OpenSSL 1.0.x can't be changed, but with
1.x.y, x=1 and on, 1.x as shared library version is sufficient.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

indent will not alter them when reformatting comments
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Add the wrapper to all public header files (Configure
generates one).  Don't bother for those that are just
lists of #define's that do renaming.
Reviewed-by: NTim Hudson <tjh@openssl.org>

The 1.0.0 branch is now OpenSSL_1_0_0-stable

This change resolves a number of problems and obviates multiple kludges.
A new feature is that you can now say "AES256" or "AES128" (not just
"AES", which enables both).

In some cases the ciphersuite list generated from a given string is
affected by this change.  I hope this is just in those cases where the
previous behaviour did not make sense.

The 0.9.8 branch is called OpenSSL_0_9_8-stable.

comes in we have required macros in place.

of OpenSSL.
Part of PR 181.

0.9.7 now lives in the branch OpenSSL_0_9_7-stable.

His comments are:

1) Changes all references for `True64' to be `Tru64', which is the correct
spelling for the OS name.

2) Makes `alpha-cc' be the same as `alpha164-cc', and adds an `alphaold-cc'
entry that is the same as the previous `alpha-cc'.  The reason is that most
people these days are using the newer compiler, so it should be the default.

3) Adds a bit of commentary to Configure, regarding the name changes of
the OS over the years, so it's not so confusing to people that haven't been
with the OS for a while.

4) Adds an `alpha-cc-rpath' target (which is *not* selected automatically
by Configure under any circumstance) that builds an RPATH into the
shared libraries.  This is explained in the comment in Configure.  It's
very very useful for people that want it, and people that don't want it
just shouldn't choose that target.

5) Adds the `-pthread' flag as the best way to get POSIX thread support
from the newer compiler.

6) Updates the Makefile targets, so that when the `alpha164-cc', `alpha-cc',
or `alpha-cc-rpath' target is what Configure is set to use, it uses a Makefile
target that includes the `-msym' option when building the shared library.
This is a performance enhancement.

7) Updates `config' so that if it detects you're running version 4 or 5
of the OS, it automatically selects `alpha-cc', but uses `alphaold-cc'
for versions 1-3 of the OS.

8) Updates the comment in opensslv.h, fixing both the OS name typo and
adding a reference to IRIX 6.x, since the shared library semantics are
virtually identical there.

accordingly.

accordingly.

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

a low profile, so we don't get discontinuity in the numbering...)

I know it's earlier than announced.  The high amount of problems in
beta1 warants this, however.