Irrelevant.

10 files changed, 0 insertions, 1564 deletions

diff --git a/lib/libssl/src/INSTALL b/lib/libssl/src/INSTALL
index 1325079f2a9..bd37bf52d2d 100644
--- a/lib/libssl/src/INSTALL
+++ b/lib/libssl/src/INSTALL
@@ -2,13 +2,6 @@
  INSTALLATION ON THE UNIX PLATFORM
  ---------------------------------
 
- [Installation on DOS (with djgpp), Windows, OpenVMS, MacOS (before MacOS X)
-  and NetWare is described in INSTALL.DJGPP, INSTALL.W32, INSTALL.VMS,
-  INSTALL.MacOS and INSTALL.NW.
-  
-  This document describes installation on operating systems in the Unix
-  family.]
-
  To install OpenSSL, you will need:
 
   * make
diff --git a/lib/libssl/src/INSTALL.DJGPP b/lib/libssl/src/INSTALL.DJGPP
deleted file mode 100644
index 0120b946b5e..00000000000
--- a/lib/libssl/src/INSTALL.DJGPP
+++ /dev/null
@@ -1,32 +0,0 @@
-
- 
- INSTALLATION ON THE DOS PLATFORM WITH DJGPP
- -------------------------------------------
-
- Openssl has been ported to DOS, but only with long filename support. If
- you wish to compile on native DOS with 8+3 filenames, you will have to
- tweak the installation yourself, including renaming files with illegal
- or duplicate names.
-
- You should have a full DJGPP environment installed, including the
- latest versions of DJGPP, GCC, BINUTILS, BASH, etc. This package
- requires that PERL and BC also be installed.
-
- All of these can be obtained from the usual DJGPP mirror sites, such as
- "ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp". You also need to have
- the WATT-32 networking package installed before you try to compile
- openssl. This can be obtained from "http://www.bgnett.no/~giva/". The
- Makefile assumes that the WATT-32 code is in directory "watt32" under
- /dev/env/DJDIR.
-
- To compile openssl, start your BASH shell. Then configure for DOS by
- running "./Configure" with appropriate arguments. The basic syntax for
- DOS is:
- ./Configure no-threads --prefix=/dev/env/DJDIR DJGPP
- 
- You may run out of DPMI selectors when running in a DOS box under
- Windows. If so, just close the BASH shell, go back to Windows, and
- restart BASH. Then run "make" again.
-
- Building openssl under DJGPP has been tested with DJGPP 2.03,
- GCC 2.952, GCC 2.953, perl 5.005_02 and perl 5.006_01.
diff --git a/lib/libssl/src/INSTALL.MacOS b/lib/libssl/src/INSTALL.MacOS
deleted file mode 100644
index 01c60d81f96..00000000000
--- a/lib/libssl/src/INSTALL.MacOS
+++ /dev/null
@@ -1,72 +0,0 @@
-OpenSSL - Port To The Macintosh OS 9 or Earlier
-===============================================
-
-Thanks to Roy Wood <roy@centricsystems.ca> initial support for Mac OS (pre
-X) is now provided. "Initial" means that unlike other platforms where you
-get an SDK and a "swiss army" openssl application, on Macintosh you only
-get one sample application which fetches a page over HTTPS(*) and dumps it
-in a window. We don't even build the test applications so that we can't
-guarantee that all algorithms are operational.
-
-Required software:
-
-- StuffIt Expander 5.5 or later, alternatively MacGzip and SUNtar;
-- Scriptable Finder;
-- CodeWarrior Pro 5;
-
-Installation procedure:
-
-- fetch the source at ftp://ftp.openssl.org/ (well, you probably already
-  did, huh?)
-- unpack the .tar.gz file:
-	- if you have StuffIt Expander then just drag it over it;
-	- otherwise uncompress it with MacGzip and then unpack with SUNtar;
-- locate MacOS folder in OpenSSL source tree and open it;
-- unbinhex mklinks.as.hqx and OpenSSL.mcp.hqx if present (**), do it
-  "in-place", i.e. unpacked files should end-up in the very same folder;
-- execute mklinks.as;
-- open OpenSSL.mcp(***) and build 'GetHTTPS PPC' target(****);
-- that's it for now;
-
-(*)	URL is hardcoded into ./MacOS/GetHTTPS.src/GetHTTPS.cpp, lines 40
-        to 42, change appropriately.
-(**)	If you use SUNtar, then it might have already unbinhexed the files
-	in question.
-(***)	The project file was saved with CW Pro 5.3. If you have an earlier
-	version and it refuses to open it, then download
-	http://www.openssl.org/~appro/OpenSSL.mcp.xml and import it
-	overwriting the original OpenSSL.mcp.
-(****)	Other targets are works in progress. If you feel like giving 'em a
-	shot, then you should know that OpenSSL* and Lib* targets are
-	supposed to be built with the GUSI, MacOS library which mimics
-	BSD sockets and some other POSIX APIs. The GUSI distribution is
-	expected to be found in the same directory as the openssl source tree,
-	i.e., in the parent directory to the one where this very file,
-	namely INSTALL.MacOS, resides. For more information about GUSI, see
-	http://www.iis.ee.ethz.ch/~neeri/macintosh/gusi-qa.html
-
-Finally some essential comments from our generous contributor:-)
-
-"I've gotten OpenSSL working on the Macintosh. It's probably a bit of a
-hack, but it works for what I'm doing. If you don't like the way I've done
-it, then feel free to change what I've done. I freely admit that I've done
-some less-than-ideal things in my port, and if you don't like the way I've
-done something, then feel free to change it-- I won't be offended!
-
-... I've tweaked "bss_sock.c" a little to call routines in a "MacSocket"
-library I wrote. My MacSocket library is a wrapper around OpenTransport,
-handling stuff like endpoint creation, reading, writing, etc. It is not
-designed as a high-performance package such as you'd use in a webserver,
-but is fine for lots of other applications. MacSocket also uses some other
-code libraries I've written to deal with string manipulations and error
-handling. Feel free to use these things in your own code, but give me
-credit and/or send me free stuff in appreciation! :-)
-
-...
-
-If you have any questions, feel free to email me as the following:
-
-roy@centricsystems.ca
-
--Roy Wood"
-
diff --git a/lib/libssl/src/INSTALL.NW b/lib/libssl/src/INSTALL.NW
deleted file mode 100644
index 609a7309e14..00000000000
--- a/lib/libssl/src/INSTALL.NW
+++ /dev/null
@@ -1,454 +0,0 @@
-
-INSTALLATION ON THE NETWARE PLATFORM
-------------------------------------
-
-Notes about building OpenSSL for NetWare.
-
-
-BUILD PLATFORM:
----------------
-The build scripts (batch files, perl scripts, etc) have been developed and
-tested on W2K.  The scripts should run fine on other Windows platforms
-(NT, Win9x, WinXP) but they have not been tested.  They may require some
-modifications.
-
-
-Supported NetWare Platforms - NetWare 5.x, NetWare 6.x:
--------------------------------------------------------
-OpenSSL can either use the WinSock interfaces introduced in NetWare 5,
-or the BSD socket interface.  Previous versions of NetWare, 4.x and 3.x,
-are only supported if OpenSSL is build for CLIB and BSD sockets;
-WinSock builds only support NetWare 5 and up.
-
-On NetWare there are two c-runtime libraries.  There is the legacy CLIB 
-interfaces and the newer LIBC interfaces.  Being ANSI-C libraries, the 
-functionality in CLIB and LIBC is similar but the LIBC interfaces are built 
-using Novell Kernal Services (NKS) which is designed to leverage 
-multi-processor environments.
-
-The NetWare port of OpenSSL can be configured to build using CLIB or LIBC.
-The CLIB build was developed and tested using NetWare 5.0 sp6.0a.  The LIBC 
-build was developed and tested using the NetWare 6.0 FCS.  
-
-The necessary LIBC functionality ships with NetWare 6.  However, earlier 
-NetWare 5.x versions will require updates in order to run the OpenSSL LIBC
-build (NetWare 5.1 SP8 is known to work).
-
-As of June 2005, the LIBC build can be configured to use BSD sockets instead
-of WinSock sockets. Call Configure (usually through netware\build.bat) using
-a target of "netware-libc-bsdsock" instead of "netware-libc".
-
-As of June 2007, support for CLIB and BSD sockets is also now available
-using a target of "netware-clib-bsdsock" instead of "netware-clib";
-also gcc builds are now supported on both Linux and Win32 (post 0.9.8e).
-
-REQUIRED TOOLS:
----------------
-Based upon the configuration and build options used, some or all of the
-following tools may be required:
-
-* Perl for Win32 - required (http://www.activestate.com/ActivePerl)
-   Used to run the various perl scripts on the build platform.
-
-* Perl 5.8.0 for NetWare v3.20 (or later) - required 
-   (http://developer.novell.com) Used to run the test script on NetWare 
-   after building.
-
-* Compiler / Linker - required:
-   Metrowerks CodeWarrior PDK 2.1 (or later) for NetWare (commercial):
-      Provides command line tools used for building.
-      Tools:
-      mwccnlm.exe  - C/C++ Compiler for NetWare
-      mwldnlm.exe  - Linker for NetWare
-      mwasmnlm.exe - x86 assembler for NetWare (if using assembly option)
-
-   gcc / nlmconv Cross-Compiler, available from Novell Forge (free):
-         http://forge.novell.com/modules/xfmod/project/?aunixnw
-
-* Assemblers - optional:
-   If you intend to build using the assembly options you will need an
-   assembler.  Work has been completed to support two assemblers, Metrowerks
-   and NASM.  However, during development, a bug was found in the Metrowerks
-   assembler which generates incorrect code.  Until this problem is fixed,
-   the Metrowerks assembler cannot be used.
-
-   mwasmnlm.exe - Metrowerks x86 assembler - part of CodeWarrior tools.
-         (version 2.2 Built Aug 23, 1999 - not useable due to code
-          generation bug)
-
-   nasmw.exe - Netwide Assembler NASM
-         version 0.98 was used in development and testing
-
-* Make Tool - required:
-   In order to build you will need a make tool.  Two make tools are
-   supported, GNU make (gmake.exe) or Microsoft nmake.exe.
-
-   make.exe - GNU make for Windows (version 3.75 used for development)
-         http://gnuwin32.sourceforge.net/packages/make.htm
-
-   nmake.exe - Microsoft make (Version 6.00.8168.0 used for development)
-         http://support.microsoft.com/kb/132084/EN-US/
-
-* Novell Developer Kit (NDK) - required: (http://developer.novell.com)
-
-   CLIB - BUILDS:
-
-      WinSock2 Developer Components for NetWare:
-         For initial development, the October 27, 2000 version was used.
-         However, future versions should also work.
-
-         NOTE:  The WinSock2 components include headers & import files for
-         NetWare, but you will also need the winsock2.h and supporting
-         headers (pshpack4.h, poppack.h, qos.h) delivered in the
-         Microsoft SDK.  Note: The winsock2.h support headers may change
-         with various versions of winsock2.h.  Check the dependencies
-         section on the NDK WinSock2 download page for the latest
-         information on dependencies. These components are unsupported by
-         Novell. They are provided as a courtesy, but it is strongly
-         suggested that all development be done using LIBC, not CLIB.
-
-         As of June 2005, the WinSock2 components are available at:
-         http://forgeftp.novell.com//ws2comp/
-
-
-      NLM and NetWare libraries for C (including CLIB and XPlat):
-         If you are going to build a CLIB version of OpenSSL, you will
-         need the CLIB headers and imports.  The March, 2001 NDK release or 
-         later is recommended.
-
-         Earlier versions should work but haven't been tested.  In recent
-         versions the import files have been consolidated and function
-         names moved.  This means you may run into link problems
-         (undefined symbols) when using earlier versions.   The functions
-         are available in earlier versions, but you will have to modifiy
-         the make files to include additional import files (see
-         openssl\util\pl\netware.pl).
-
-
-   LIBC - BUILDS:
-   
-      Libraries for C (LIBC) - LIBC headers and import files
-         If you are going to build a LIBC version of OpenSSL, you will
-         need the LIBC headers and imports.  The March 14, 2002 NDK release or
-         later is required.  
-         
-         NOTE: The LIBC SDK includes the necessary WinSock2 support.
-         It is not necessary to download the WinSock2 NDK when building for
-         LIBC. The LIBC SDK also includes the appropriate BSD socket support
-         if configuring to use BSD sockets.
-
-
-BUILDING:
----------
-Before building, you will need to set a few environment variables.  You can
-set them manually or you can modify the "netware\set_env.bat" file.
-
-The set_env.bat file is a template you can use to set up the path
-and environment variables you will need to build.  Modify the
-various lines to point to YOUR tools and run set_env.bat.
-
-   netware\set_env.bat <target> [compiler]
-
-      target        - "netware-clib" - CLIB NetWare build
-                    - "netware-libc" - LIBC NetWare build
-
-      compiler      - "gnuc"         - GNU GCC Compiler
-                    - "codewarrior"  - MetroWerks CodeWarrior (default)
-
-If you don't use set_env.bat, you will need to set up the following
-environment variables:
-
-   PATH - Set PATH to point to the tools you will use.
-
-   INCLUDE - The location of the NDK include files.
-         
-            CLIB ex: set INCLUDE=c:\ndk\nwsdk\include\nlm
-            LIBC ex: set INCLUDE=c:\ndk\libc\include
-
-   PRELUDE - The absolute path of the prelude object to link with.  For
-            a CLIB build it is recommended you use the "clibpre.o" files shipped
-            with the Metrowerks PDK for NetWare.  For a LIBC build you should 
-            use the "libcpre.o" file delivered with the LIBC NDK components.
-
-            CLIB ex: set PRELUDE=c:\ndk\nwsdk\imports\clibpre.o
-            LIBC ex: set PRELUDE=c:\ndk\libc\imports\libcpre.o
-
-   IMPORTS - The locaton of the NDK import files.
-
-            CLIB ex: set IMPORTS=c:\ndk\nwsdk\imports
-            LIBC ex: set IMPORTS=c:\ndk\libc\imports
-
-
-In order to build, you need to run the Perl scripts to configure the build
-process and generate a make file.  There is a batch file,
-"netware\build.bat", to automate the process.
-
-Build.bat runs the build configuration scripts and generates a make file.
-If an assembly option is specified, it also runs the scripts to generate 
-the assembly code.  Always run build.bat from the "openssl" directory.
-
-   netware\build [target] [debug opts] [assembly opts] [configure opts]
-
-      target        - "netware-clib" - CLIB NetWare build (WinSock Sockets)
-                    - "netware-clib-bsdsock" - CLIB NetWare build (BSD Sockets)
-                    - "netware-libc" - LIBC NetWare build (WinSock Sockets)
-                    - "netware-libc-bsdsock" - LIBC NetWare build (BSD Sockets)
- 
-      debug opts    - "debug"  - build debug
-
-      assembly opts - "nw-mwasm" - use Metrowerks assembler
-                      "nw-nasm"  - use NASM assembler
-                      "no-asm"   - don't use assembly
-
-      configure opts- all unrecognized arguments are passed to the
-                      perl 'configure' script. See that script for
-                      internal documentation regarding options that
-                      are available.
-
-   examples:
-
-      CLIB build, debug, without assembly:
-         netware\build.bat netware-clib debug no-asm
-
-      LIBC build, non-debug, using NASM assembly, add mdc2 support:
-         netware\build.bat netware-libc nw-nasm enable-mdc2
-
-      LIBC build, BSD sockets, non-debug, without assembly:
-         netware\build.bat netware-libc-bsdsock no-asm
-
-Running build.bat generates a make file to be processed by your make 
-tool (gmake or nmake):
-
-   CLIB ex: gmake -f netware\nlm_clib_dbg.mak 
-   LIBC ex: gmake -f netware\nlm_libc.mak 
-   LIBC ex: gmake -f netware\nlm_libc_bsdsock.mak 
-
-
-You can also run the build scripts manually if you do not want to use the
-build.bat file.  Run the following scripts in the "\openssl"
-subdirectory (in the order listed below):
-
-   perl configure no-asm [other config opts] [netware-clib|netware-libc|netware-libc-bsdsock]
-      configures no assembly build for specified netware environment
-      (CLIB or LIBC).
-
-   perl util\mkfiles.pl >MINFO
-      generates a listing of source files (used by mk1mf)
-
-   perl util\mk1mf.pl no-asm [other config opts] [netware-clib|netware-libc|netware-libc-bsdsock >netware\nlm.mak
-      generates the makefile for NetWare
-
-   gmake -f netware\nlm.mak
-      build with the make tool (nmake.exe also works)
-
-NOTE:  If you are building using the assembly option, you must also run the
-various Perl scripts to generate the assembly files.  See build.bat
-for an example of running the various assembly scripts.  You must use the
-"no-asm" option to build without assembly.  The configure and mk1mf scripts
-also have various other options.  See the scripts for more information.
-
-
-The output from the build is placed in the following directories:
-
-   CLIB Debug build:
-      out_nw_clib.dbg     - static libs & test nlm(s)
-      tmp_nw_clib.dbg     - temporary build files
-      outinc_nw_clib      - necessary include files
-
-   CLIB Non-debug build:
-      out_nw_clib         - static libs & test nlm(s)
-      tmp_nw_clib         - temporary build files
-      outinc_nw_clib      - necesary include files
-
-   LIBC Debug build:
-      out_nw_libc.dbg     - static libs & test nlm(s)
-      tmp_nw_libc.dbg     - temporary build files
-      outinc_nw_libc      - necessary include files
-
-   LIBC Non-debug build:
-      out_nw_libc         - static libs & test nlm(s)
-      tmp_nw_libc         - temporary build files
-      outinc_nw_libc      - necesary include files
-
-
-TESTING:
---------
-The build process creates the OpenSSL static libs ( crypto.lib, ssl.lib,
-rsaglue.lib ) and several test programs.  You should copy the test programs
-to your NetWare server and run the tests.
-
-The batch file "netware\cpy_tests.bat" will copy all the necessary files
-to your server for testing.  In order to run the batch file, you need a
-drive mapped to your target server.  It will create an "OpenSSL" directory
-on the drive and copy the test files to it.  CAUTION: If a directory with the
-name of "OpenSSL" already exists, it will be deleted.
-
-To run cpy_tests.bat:
-
-   netware\cpy_tests [output directory] [NetWare drive]
-
-      output directory - "out_nw_clib.dbg", "out_nw_libc", etc.
-      NetWare drive    - drive letter of mapped drive
-
-      CLIB ex: netware\cpy_tests out_nw_clib m:
-      LIBC ex: netware\cpy_tests out_nw_libc m:
-
-
-The Perl script, "do_tests.pl", in the "OpenSSL" directory on the server
-should be used to execute the tests.  Before running the script, make sure
-your SEARCH PATH includes the "OpenSSL" directory.  For example, if you
-copied the files to the "sys:" volume you use the command:
-
-   SEARCH ADD SYS:\OPENSSL
-
-
-To run do_tests.pl type (at the console prompt):
-
-   perl \openssl\do_tests.pl [options]
-
-      options:
-         -p    - pause after executing each test
-
-The do_tests.pl script generates a log file "\openssl\test_out\tests.log"
-which should be reviewed for errors.  Any errors will be denoted by the word
-"ERROR" in the log.
-
-DEVELOPING WITH THE OPENSSL SDK:
---------------------------------
-Now that everything is built and tested, you are ready to use the OpenSSL
-libraries in your development.
-
-There is no real installation procedure, just copy the static libs and
-headers to your build location.  The libs (crypto.lib & ssl.lib) are
-located in the appropriate "out_nw_XXXX" directory 
-(out_nw_clib, out_nw_libc, etc).  
-
-The headers are located in the appropriate "outinc_nw_XXX" directory 
-(outinc_nw_clib, outinc_nw_libc).  
-
-One suggestion is to create the following directory 
-structure for the OpenSSL SDK:
-
-   \openssl
-      |- bin
-      |   |- openssl.nlm
-      |   |- (other tests you want)
-      |
-      |- lib
-      |   | - crypto.lib
-      |   | - ssl.lib
-      |
-      |- include
-      |   | - openssl
-      |   |    | - (all the headers in "outinc_nw\openssl")
-
-
-The program "openssl.nlm" can be very useful.  It has dozens of
-options and you may want to keep it handy for debugging, testing, etc.
-
-When building your apps using OpenSSL, define "NETWARE".  It is needed by
-some of the OpenSSL headers.  One way to do this is with a compile option,
-for example "-DNETWARE".
-
-
-
-NOTES:
-------
-
-Resource leaks in Tests
-------------------------
-Some OpenSSL tests do not clean up resources and NetWare reports
-the resource leaks when the tests unload.  If this really bugs you,
-you can stop the messages by setting the developer option off at the console
-prompt (set developer option = off).  Or better yet, fix the tests to
-clean up the resources!
-
-
-Multi-threaded Development
----------------------------
-The NetWare version of OpenSSL is thread-safe, however multi-threaded
-applications must provide the necessary locking function callbacks.  This
-is described in doc\threads.doc.  The file "openssl-x.x.x\crypto\threads\mttest.c"
-is a multi-threaded test program and demonstrates the locking functions.
-
-
-What is openssl2.nlm?
----------------------
-The openssl program has numerous options and can be used for many different
-things.  Many of the options operate in an interactive mode requiring the
-user to enter data.  Because of this, a default screen is created for the
-program.  However, when running the test script it is not desirable to
-have a seperate screen.  Therefore, the build also creates openssl2.nlm.
-Openssl2.nlm is functionally identical but uses the console screen.
-Openssl2 can be used when a non-interactive mode is desired.
-
-NOTE:  There are may other possibilities (command line options, etc)
-which could have been used to address the screen issue.  The openssl2.nlm
-option was chosen because it impacted only the build not the code.
-
-
-Why only static libraries?
---------------------------
-Globals, globals, and more globals.  The OpenSSL code uses many global
-variables that are allocated and initialized when used for the first time.
-
-On NetWare, most applications (at least historically) run in the kernel.
-When running in the kernel, there is one instance of global variables.
-For regular application type NLM(s) this isn't a problem because they are
-the only ones using the globals.  However, for a library NLM (an NLM which
-exposes functions and has no threads of execution), the globals cause
-problems.  Applications could inadvertently step on each other if they
-change some globals.  Even worse, the first application that triggers a
-global to be allocated and initialized has the allocated memory charged to
-itself.  Now when that application unloads, NetWare will clean up all the
-applicaton's memory.  The global pointer variables inside OpenSSL now
-point to freed memory.  An abend waiting to happen!
-
-To work correctly in the kernel, library NLM(s) that use globals need to
-provide a set of globals (instance data) for each application.  Another
-option is to require the library only be loaded in a protected address
-space along with the application using it.
-
-Modifying the OpenSSL code to provide a set of globals (instance data) for
-each application isn't technically difficult, but due to the large number
-globals it would require substantial code changes and it wasn't done.  Hence,
-the build currently only builds static libraries which are then linked
-into each application.
-
-NOTE:  If you are building a library NLM that uses the OpenSSL static
-libraries, you will still have to deal with the global variable issue.
-This is because when you link in the OpenSSL code you bring in all the
-globals.  One possible solution for the global pointer variables is to
-register memory functions with OpenSSL which allocate memory and charge it
-to your library NLM (see the function CRYPTO_set_mem_functions).  However,
-be aware that now all memory allocated by OpenSSL is charged to your NLM.
-
-
-CodeWarrior Tools and W2K
----------------------------
-There have been problems reported with the CodeWarrior Linker
-(mwldnlm.exe) in the PDK 2.1 for NetWare when running on Windows 2000.  The
-problems cause the link step to fail.  The only work around is to obtain an
-updated linker from Metrowerks.  It is expected Metrowerks will release
-PDK 3.0 (in beta testing at this time - May, 2001) in the near future which
-will fix these problems.
-
-
-Makefile "vclean"
-------------------
-The generated makefile has a "vclean" target which cleans up the build
-directories.  If you have been building successfully and suddenly
-experience problems, use "vclean" (gmake -f netware\nlm_xxxx.mak vclean) and retry.
-
-
-"Undefined Symbol" Linker errors
---------------------------------
-There have been linker errors reported when doing a CLIB build.  The problems
-occur because some versions of the CLIB SDK import files inadvertently 
-left out some symbols.  One symbol in particular is "_lrotl".  The missing
-functions are actually delivered in the binaries, but they were left out of
-the import files.  The issues should be fixed in the September 2001 release 
-of the NDK.  If you experience the problems you can temporarily
-work around it by manually adding the missing symbols to your version of 
-"clib.imp".
-
diff --git a/lib/libssl/src/INSTALL.OS2 b/lib/libssl/src/INSTALL.OS2
deleted file mode 100644
index 530316db180..00000000000
--- a/lib/libssl/src/INSTALL.OS2
+++ /dev/null
@@ -1,31 +0,0 @@
- 
- Installation on OS/2
- --------------------
-
- You need to have the following tools installed:
-
-  * EMX GCC
-  * PERL
-  * GNU make
-
-
- To build the makefile, run
-
- > os2\os2-emx
-
- This will configure OpenSSL and create OS2-EMX.mak which you then use to 
- build the OpenSSL libraries & programs by running
-
- > make -f os2-emx.mak
-
- If that finishes successfully you will find the libraries and programs in the
- "out" directory.
-
- Alternatively, you can make a dynamic build that puts the library code into
- crypto.dll and ssl.dll by running
-
- > make -f os2-emx-dll.mak
-
- This will build the above mentioned dlls and a matching pair of import
- libraries in the "out_dll" directory along with the set of test programs
- and the openssl application.
diff --git a/lib/libssl/src/INSTALL.VMS b/lib/libssl/src/INSTALL.VMS
deleted file mode 100644
index e5d43a57ab5..00000000000
--- a/lib/libssl/src/INSTALL.VMS
+++ /dev/null
@@ -1,293 +0,0 @@
-			VMS Installation instructions
-			written by Richard Levitte
-			<richard@levitte.org>
-
-
-Intro:
-======
-
-This file is divided in the following parts:
-
-  Requirements			- Mandatory reading.
-  Checking the distribution	- Mandatory reading.
-  Compilation			- Mandatory reading.
-  Logical names			- Mandatory reading.
-  Test				- Mandatory reading.
-  Installation			- Mandatory reading.
-  Backward portability		- Read if it's an issue.
-  Possible bugs or quirks	- A few warnings on things that
-				  may go wrong or may surprise you.
-  TODO				- Things that are to come.
-
-
-Requirements:
-=============
-
-To build and install OpenSSL, you will need:
-
- * DEC C or some other ANSI C compiler.  VAX C is *not* supported.
-   [Note: OpenSSL has only been tested with DEC C.  Compiling with 
-    a different ANSI C compiler may require some work]
-
-Checking the distribution:
-==========================
-
-There have been reports of places where the distribution didn't quite get
-through, for example if you've copied the tree from a NFS-mounted Unix
-mount point.
-
-The easiest way to check if everything got through as it should is to check
-for one of the following files:
-
-	[.CRYPTO]OPENSSLCONF.H_IN
-	[.CRYPTO]OPENSSLCONF_H.IN
-
-They should never exist both at once, but one of them should (preferably
-the first variant).  If you can't find any of those two, something went
-wrong.
-
-The best way to get a correct distribution is to download the gzipped tar
-file from ftp://ftp.openssl.org/source/, use GUNZIP to uncompress it and
-use VMSTAR to unpack the resulting tar file.
-
-GUNZIP is available in many places on the net.  One of the distribution
-points is the WKU software archive, ftp://ftp.wku.edu/vms/fileserv/ .
-
-VMSTAR is also available in many places on the net.  The recommended place
-to find information about it is http://www.free.lp.se/vmstar/ .
-
-
-Compilation:
-============
-
-I've used the very good command procedures written by Robert Byer
-<byer@mail.all-net.net>, and just slightly modified them, making
-them slightly more general and easier to maintain.
-
-You can actually compile in almost any directory separately.  Look
-for a command procedure name xxx-LIB.COM (in the library directories)
-or MAKExxx.COM (in the program directories) and read the comments at
-the top to understand how to use them.  However, if you want to
-compile all you can get, the simplest is to use MAKEVMS.COM in the top
-directory.  The syntax is the following:
-
-  @MAKEVMS <option> <bits> <debug-p> [<compiler>]
-
-<option> must be one of the following:
-
-      ALL       Just build "everything".
-      CONFIG    Just build the "[.CRYPTO]OPENSSLCONF.H" file.
-      BUILDINF  Just build the "[.INCLUDE]BUILDINF.H" file.
-      SOFTLINKS Just copies some files, to simulate Unix soft links.
-      BUILDALL  Same as ALL, except CONFIG, BUILDINF and SOFTLINKS aren't done.
-      RSAREF    Just build the "[.xxx.EXE.RSAREF]LIBRSAGLUE.OLB" library.
-      CRYPTO    Just build the "[.xxx.EXE.CRYPTO]LIBCRYPTO.OLB" library.
-      SSL       Just build the "[.xxx.EXE.SSL]LIBSSL.OLB" library.
-      SSL_TASK  Just build the "[.xxx.EXE.SSL]SSL_TASK.EXE" program.
-      TEST      Just build the "[.xxx.EXE.TEST]" test programs for OpenSSL.
-      APPS      Just build the "[.xxx.EXE.APPS]" application programs for OpenSSL.
-
-<bits> must be one of the following:
-
-      ""        compile using default pointer size
-      32        compile using 32 bit pointer size
-      64        compile using 64 bit pointer size
-
-<debug-p> must be one of the following:
-
-      DEBUG     compile with debugging info (will not optimize)
-      NODEBUG   compile without debugging info (will optimize)
-
-<compiler> must be one of the following:
-
-      DECC      For DEC C.
-      GNUC      For GNU C.
-
-
-You will find the crypto library in [.xxx.EXE.CRYPTO] (where xxx is VAX,
-ALPHA or IA64), called SSL_LIBCRYPTO32.OLB or SSL_LIBCRYPTO.OLB depending
-on how it was built.  You will find the SSL library in [.xxx.EXE.SSL],
-named SSL_LIBSSL32.OLB or SSL_LIBSSL.OLB, and you will find a bunch of
-useful programs in [.xxx.EXE.APPS].  However, these shouldn't be used
-right off unless it's just to test them.  For production use, make sure
-you install first, see Installation below.
-
-Note 1: Some programs in this package require a TCP/IP library.
-
-Note 2: if you want to compile the crypto library only, please make sure
-        you have at least done a @MAKEVMS CONFIG, a @MAKEVMS BUILDINF and
-        a @MAKEVMS SOFTLINKS.  A lot of things will break if you don't.
-
-
-Logical names:
-==============
-
-There are a few things that can't currently be given through the command
-line.  Instead, logical names are used.
-
-Currently, the logical names supported are:
-
-      OPENSSL_NO_ASM    with value YES, the assembler parts of OpenSSL will
-                        not be used.  Instead, plain C implementations are
-                        used.  This is good to try if something doesn't work.
-      OPENSSL_NO_'alg'  with value YES, the corresponding crypto algorithm
-                        will not be implemented.  Supported algorithms to
-                        do this with are: RSA, DSA, DH, MD2, MD4, MD5, RIPEMD,
-                        SHA, DES, MDC2, CR2, RC4, RC5, IDEA, BF, CAST, HMAC,
-                        SSL2.  So, for example, having the logical name
-                        OPENSSL_NO_RSA with the value YES means that the
-                        LIBCRYPTO.OLB library will not contain an RSA
-                        implementation.
-
-
-Test:
-=====
-
-Testing is very simple, just do the following:
-
-  @[.TEST]TESTS
-
-If a test fails, try with defining the logical name OPENSSL_NO_ASM (yes,
-it's an ugly hack!) and rebuild. Please send a bug report to
-<openssl-bugs@openssl.org>, including the output of "openssl version -a"
-and of the failed test.
-
-
-Installation:
-=============
-
-Installation is easy, just do the following:
-
-  @INSTALL <root> <bits>
-
-<root> is the directory in which everything will be installed,
-subdirectories, libraries, header files, programs and startup command
-procedures.
-
-<bits> works the same way as for MAKEVMS.COM
-
-N.B.: INSTALL.COM builds a new directory structure, different from
-the directory tree where you have now build OpenSSL.
-
-In the [.VMS] subdirectory of the installation, you will find the
-following command procedures:
-
-  OPENSSL_STARTUP.COM
-
-        defines all needed logical names.  Takes one argument that
-        tells it in what logical name table to insert the logical
-        names.  If you insert if it SYS$MANAGER:SYSTARTUP_VMS.COM, the
-        call should look like this: 
-
-          @openssldev:[openssldir.VMS]OPENSSL_STARTUP "/SYSTEM"
-
-  OPENSSL_UTILS.COM
-
-        sets up the symbols to the applications.  Should be called
-        from for example SYS$MANAGER:SYLOGIN.COM 
-
-  OPENSSL_UNDO.COM
-
-	deassigns the logical names created with OPENSSL_STARTUP.COM.
-
-The logical names that are set up are the following:
-
-  SSLROOT       a dotted concealed logical name pointing at the
-                root directory.
-
-  SSLCERTS      Initially an empty directory, this is the default
-		location for certificate files.
-  SSLPRIVATE	Initially an empty directory, this is the default
-		location for private key files.
-
-  SSLEXE        Contains the openssl binary and a few other utility
-		programs.
-  SSLINCLUDE    Contains the header files needed if you want to
-		compile programs with libcrypto or libssl.
-  SSLLIB        Contains the OpenSSL library files themselves:
-  		- SSL_LIBCRYPTO32.OLB and SSL_LIBSSL32.OLB or
-		- SSL_LIBCRYPTO.OLB and SSL_LIBSSL.OLB
-
-  OPENSSL	Same as SSLINCLUDE.  This is because the standard
-		way to include OpenSSL header files from version
-		0.9.3 and on is:
-
-			#include <openssl/header.h>
-
-		For more info on this issue, see the INSTALL. file
-		(the NOTE in section 4 of "Installation in Detail").
-		You don't need to "deleting old header files"!!!
-
-
-Backward portability:
-=====================
-
-One great problem when you build a library is making sure it will work
-on as many versions of VMS as possible.  Especially, code compiled on
-OpenVMS version 7.x and above tend to be unusable in version 6.x or
-lower, because some C library routines have changed names internally
-(the C programmer won't usually see it, because the old name is
-maintained through C macros).  One obvious solution is to make sure
-you have a development machine with an old enough version of OpenVMS.
-However, if you are stuck with a bunch of Alphas running OpenVMS version
-7.1, you seem to be out of luck.  Fortunately, the DEC C header files
-are cluttered with conditionals that make some declarations and definitions
-dependent on the OpenVMS version or the C library version, *and* you
-can use those macros to simulate older OpenVMS or C library versions,
-by defining the macros _VMS_V6_SOURCE, __VMS_VER and __CTRL_VER with
-correct values.  In the compilation scripts, I've provided the possibility
-for the user to influence the creation of such macros, through a bunch of
-symbols, all having names starting with USER_.  Here's the list of them:
-
-  USER_CCFLAGS		 - Used to give additional qualifiers to the
-			   compiler.  It can't be used to define macros
-			   since the scripts will do such things as well.
-			   To do such things, use USER_CCDEFS.
-  USER_CCDEFS		 - Used to define macros on the command line.  The
-			   value of this symbol will be inserted inside a
-			   /DEFINE=(...).
-  USER_CCDISABLEWARNINGS - Used to disable some warnings.  The value is
-			   inserted inside a /DISABLE=WARNING=(...).
-
-So, to maintain backward compatibility with older VMS versions, do the
-following before you start compiling:
-
-  $ USER_CCDEFS := _VMS_V6_SOURCE=1,__VMS_VER=60000000,__CRTL_VER=60000000
-  $ USER_CCDISABLEWARNINGS := PREOPTW
-
-The USER_CCDISABLEWARNINGS is there because otherwise, DEC C will complain
-that those macros have been changed.
-
-Note: Currently, this is only useful for library compilation.  The
-      programs will still be linked with the current version of the
-      C library shareable image, and will thus complain if they are
-      faced with an older version of the same C library shareable image.
-      This will probably be fixed in a future revision of OpenSSL.
-
-
-Possible bugs or quirks:
-========================
-
-I'm not perfectly sure all the programs will use the SSLCERTS:
-directory by default, it may very well be that you have to give them
-extra arguments.  Please experiment.
-
-
-TODO:
-=====
-
-There are a few things that need to be worked out in the VMS version of
-OpenSSL, still:
-
-- Description files. ("Makefile's" :-))
-- Script code to link an already compiled build tree.
-- A VMSINSTALlable version (way in the future, unless someone else hacks).
-- shareable images (DLL for you Windows folks).
-
-There may be other things that I have missed and that may be desirable.
-Please send mail to <openssl-users@openssl.org> or to me directly if you
-have any ideas.
-
---
-Richard Levitte <richard@levitte.org>
-2000-02-27, 2011-03-18
diff --git a/lib/libssl/src/INSTALL.W32 b/lib/libssl/src/INSTALL.W32
deleted file mode 100644
index 80e538273e9..00000000000
--- a/lib/libssl/src/INSTALL.W32
+++ /dev/null
@@ -1,325 +0,0 @@
- 
- INSTALLATION ON THE WIN32 PLATFORM
- ----------------------------------
-
- [Instructions for building for Windows CE can be found in INSTALL.WCE]
- [Instructions for building for Win64 can be found in INSTALL.W64]
-
- Here are a few comments about building OpenSSL for Win32 environments,
- such as Windows NT and Windows 9x. It should be noted though that
- Windows 9x are not ordinarily tested. Its mention merely means that we
- attempt to maintain certain programming discipline and pay attention
- to backward compatibility issues, in other words it's kind of expected
- to work on Windows 9x, but no regression tests are actually performed.
-
- On additional note newer OpenSSL versions are compiled and linked with
- Winsock 2. This means that minimum OS requirement was elevated to NT 4
- and Windows 98 [there is Winsock 2 update for Windows 95 though].
-
- - you need Perl for Win32.  Unless you will build on Cygwin, you will need
-   ActiveState Perl, available from http://www.activestate.com/ActivePerl.
-
- - one of the following C compilers:
-
-  * Visual C++
-  * Borland C
-  * GNU C (Cygwin or MinGW)
-
-- Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/
-  is required if you intend to utilize assembler modules. Note that NASM
-  is now the only supported assembler.
-
- If you are compiling from a tarball or a Git snapshot then the Win32 files
- may well be not up to date. This may mean that some "tweaking" is required to
- get it all to work. See the trouble shooting section later on for if (when?)
- it goes wrong.
-
- Visual C++
- ----------
-
- If you want to compile in the assembly language routines with Visual
- C++, then you will need already mentioned Netwide Assembler binary,
- nasmw.exe or nasm.exe, to be available on your %PATH%.
-
- Firstly you should run Configure with platform VC-WIN32:
-
- > perl Configure VC-WIN32 --prefix=c:\some\openssl\dir
-
- Where the prefix argument specifies where OpenSSL will be installed to.
-
- Next you need to build the Makefiles and optionally the assembly
- language files:
-
- - If you are using NASM then run:
-
-   > ms\do_nasm
-
- - If you don't want to use the assembly language files at all then run:
-
-   > perl Configure VC-WIN32 no-asm --prefix=c:/some/openssl/dir
-   > ms\do_ms
-
- If you get errors about things not having numbers assigned then check the
- troubleshooting section: you probably won't be able to compile it as it
- stands.
-
- Then from the VC++ environment at a prompt do:
-
- > nmake -f ms\ntdll.mak
-
- If all is well it should compile and you will have some DLLs and
- executables in out32dll. If you want to try the tests then do:
- 
- > nmake -f ms\ntdll.mak test
-
-
- To install OpenSSL to the specified location do:
-
- > nmake -f ms\ntdll.mak install
-
- Tweaks:
-
- There are various changes you can make to the Win32 compile
- environment. By default the library is not compiled with debugging
- symbols. If you use the platform debug-VC-WIN32 instead of VC-WIN32
- then debugging symbols will be compiled in.
-
- By default in 1.0.0 OpenSSL will compile builtin ENGINES into the
- separate shared librariesy. If you specify the "enable-static-engine"
- option on the command line to Configure the shared library build
- (ms\ntdll.mak) will compile the engines into libeay32.dll instead.
-
- The default Win32 environment is to leave out any Windows NT specific
- features.
-
- If you want to enable the NT specific features of OpenSSL (currently
- only the logging BIO) follow the instructions above but call the batch
- file do_nt.bat instead of do_ms.bat.
-
- You can also build a static version of the library using the Makefile
- ms\nt.mak
-
-
- Borland C++ builder 5
- ---------------------
-
- * Configure for building with Borland Builder:
-   > perl Configure BC-32
-
- * Create the appropriate makefile
-   > ms\do_nasm
-
- * Build
-   > make -f ms\bcb.mak
-
- Borland C++ builder 3 and 4
- ---------------------------
-
- * Setup PATH. First must be GNU make then bcb4/bin 
-
- * Run ms\bcb4.bat
-
- * Run make:
-   > make -f bcb.mak
-
- GNU C (Cygwin)
- --------------
-
- Cygwin implements a Posix/Unix runtime system (cygwin1.dll) on top of
- Win32 subsystem and provides a bash shell and GNU tools environment.
- Consequently, a make of OpenSSL with Cygwin is virtually identical to
- Unix procedure. It is also possible to create Win32 binaries that only
- use the Microsoft C runtime system (msvcrt.dll or crtdll.dll) using
- MinGW. MinGW can be used in the Cygwin development environment or in a
- standalone setup as described in the following section.
-
- To build OpenSSL using Cygwin:
-
- * Install Cygwin (see http://cygwin.com/)
-
- * Install Perl and ensure it is in the path. Both Cygwin perl
-   (5.6.1-2 or newer) and ActivePerl work.
-
- * Run the Cygwin bash shell
-
- * $ tar zxvf openssl-x.x.x.tar.gz
-   $ cd openssl-x.x.x
-
-   To build the Cygwin version of OpenSSL:
-
-   $ ./config
-   [...]
-   $ make
-   [...]
-   $ make test
-   $ make install
-
-   This will create a default install in /usr/local/ssl.
-
-   To build the MinGW version (native Windows) in Cygwin:
-
-   $ ./Configure mingw
-   [...]
-   $ make
-   [...]
-   $ make test
-   $ make install
-
- Cygwin Notes:
-
- "make test" and normal file operations may fail in directories
- mounted as text (i.e. mount -t c:\somewhere /home) due to Cygwin
- stripping of carriage returns. To avoid this ensure that a binary
- mount is used, e.g. mount -b c:\somewhere /home.
-
- "bc" is not provided in older Cygwin distribution.  This causes a
- non-fatal error in "make test" but is otherwise harmless.  If
- desired and needed, GNU bc can be built with Cygwin without change.
-
- GNU C (MinGW/MSYS)
- -------------
-
- * Compiler and shell environment installation:
-
-   MinGW and MSYS are available from http://www.mingw.org/, both are
-   required. Run the installers and do whatever magic they say it takes
-   to start MSYS bash shell with GNU tools on its PATH.
-
-   N.B. Since source tar-ball can contain symbolic links, it's essential
-   that you use accompanying MSYS tar to unpack the source. It will
-   either handle them in one way or another or fail to extract them,
-   which does the trick too. Latter means that you may safely ignore all
-   "cannot create symlink" messages, as they will be "re-created" at
-   configure stage by copying corresponding files. Alternative programs
-   were observed to create empty files instead, which results in build
-   failure.
-
- * Compile OpenSSL:
-
-   $ ./config
-   [...]
-   $ make
-   [...]
-   $ make test
-
-   This will create the library and binaries in root source directory
-   and openssl.exe application in apps directory.
-
-   It is also possible to cross-compile it on Linux by configuring
-   with './Configure --cross-compile-prefix=i386-mingw32- mingw ...'.
-   'make test' is naturally not applicable then.
-
-   libcrypto.a and libssl.a are the static libraries. To use the DLLs,
-   link with libeay32.a and libssl32.a instead.
-
-   See troubleshooting if you get error messages about functions not
-   having a number assigned.
-
- Installation
- ------------
-
- If you used the Cygwin procedure above, you have already installed and
- can skip this section.  For all other procedures, there's currently no real
- installation procedure for Win32.  There are, however, some suggestions:
-
-    - do nothing.  The include files are found in the inc32/ subdirectory,
-      all binaries are found in out32dll/ or out32/ depending if you built
-      dynamic or static libraries.
-
-    - do as is written in INSTALL.Win32 that comes with modssl:
-
-	$ md c:\openssl 
-	$ md c:\openssl\bin
-	$ md c:\openssl\lib
-	$ md c:\openssl\include
-	$ md c:\openssl\include\openssl
-	$ copy /b inc32\openssl\*       c:\openssl\include\openssl
-	$ copy /b out32dll\ssleay32.lib c:\openssl\lib
-	$ copy /b out32dll\libeay32.lib c:\openssl\lib
-	$ copy /b out32dll\ssleay32.dll c:\openssl\bin
-	$ copy /b out32dll\libeay32.dll c:\openssl\bin
-	$ copy /b out32dll\openssl.exe  c:\openssl\bin
-
-      Of course, you can choose another device than c:.  C: is used here
-      because that's usually the first (and often only) harddisk device.
-      Note: in the modssl INSTALL.Win32, p: is used rather than c:.
-
-
- Troubleshooting
- ---------------
-
- Since the Win32 build is only occasionally tested it may not always compile
- cleanly.  If you get an error about functions not having numbers assigned
- when you run ms\do_ms then this means the Win32 ordinal files are not up to
- date. You can do:
-
- > perl util\mkdef.pl crypto ssl update
-
- then ms\do_XXX should not give a warning any more. However the numbers that
- get assigned by this technique may not match those that eventually get
- assigned in the Git tree: so anything linked against this version of the
- library may need to be recompiled.
-
- If you get errors about unresolved symbols there are several possible
- causes.
-
- If this happens when the DLL is being linked and you have disabled some
- ciphers then it is possible the DEF file generator hasn't removed all
- the disabled symbols: the easiest solution is to edit the DEF files manually
- to delete them. The DEF files are ms\libeay32.def ms\ssleay32.def.
-
- Another cause is if you missed or ignored the errors about missing numbers
- mentioned above.
-
- If you get warnings in the code then the compilation will halt.
-
- The default Makefile for Win32 halts whenever any warnings occur. Since VC++
- has its own ideas about warnings which don't always match up to other
- environments this can happen. The best fix is to edit the file with the
- warning in and fix it. Alternatively you can turn off the halt on warnings by
- editing the CFLAG line in the Makefile and deleting the /WX option.
-
- You might get compilation errors. Again you will have to fix these or report
- them.
-
- One final comment about compiling applications linked to the OpenSSL library.
- If you don't use the multithreaded DLL runtime library (/MD option) your
- program will almost certainly crash because malloc gets confused -- the
- OpenSSL DLLs are statically linked to one version, the application must
- not use a different one.  You might be able to work around such problems
- by adding CRYPTO_malloc_init() to your program before any calls to the
- OpenSSL libraries: This tells the OpenSSL libraries to use the same
- malloc(), free() and realloc() as the application.  However there are many
- standard library functions used by OpenSSL that call malloc() internally
- (e.g. fopen()), and OpenSSL cannot change these; so in general you cannot
- rely on CRYPTO_malloc_init() solving your problem, and you should
- consistently use the multithreaded library.
-
- Linking your application
- ------------------------
-
- If you link with static OpenSSL libraries [those built with ms/nt.mak],
- then you're expected to additionally link your application with
- WS2_32.LIB, ADVAPI32.LIB, GDI32.LIB and USER32.LIB. Those developing
- non-interactive service applications might feel concerned about linking
- with the latter two, as they are justly associated with interactive
- desktop, which is not available to service processes. The toolkit is
- designed to detect in which context it's currently executed, GUI,
- console app or service, and act accordingly, namely whether or not to
- actually make GUI calls. Additionally those who wish to
- /DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL and actually keep them
- off service process should consider implementing and exporting from
- .exe image in question own _OPENSSL_isservice not relying on USER32.DLL.
- E.g., on Windows Vista and later you could:
-
-	__declspec(dllexport) __cdecl BOOL _OPENSSL_isservice(void)
-	{   DWORD sess;
-	    if (ProcessIdToSessionId(GetCurrentProcessId(),&sess))
-	        return sess==0;
-	    return FALSE;
-	}
-
- If you link with OpenSSL .DLLs, then you're expected to include into
- your application code small "shim" snippet, which provides glue between
- OpenSSL BIO layer and your compiler run-time. Look up OPENSSL_Applink
- reference page for further details.
diff --git a/lib/libssl/src/INSTALL.W64 b/lib/libssl/src/INSTALL.W64
deleted file mode 100644
index 9fa7a192056..00000000000
--- a/lib/libssl/src/INSTALL.W64
+++ /dev/null
@@ -1,66 +0,0 @@
-
- INSTALLATION ON THE WIN64 PLATFORM
- ----------------------------------
-
- Caveat lector
- -------------
-
- As of moment of this writing Win64 support is classified "initial"
- for the following reasons.
-
- - No assembler modules are engaged upon initial 0.9.8 release.
- - API might change within 0.9.8 life-span, *but* in a manner which
-   doesn't break backward binary compatibility. Or in other words,
-   application programs compiled with initial 0.9.8 headers will
-   be expected to work with future minor release .DLL without need
-   to re-compile, even if future minor release features modified API.
- - Above mentioned API modifications have everything to do with
-   elimination of a number of limitations, which are normally
-   considered inherent to 32-bit platforms. Which in turn is why they
-   are treated as limitations on 64-bit platform such as Win64:-)
-   The current list comprises [but not necessarily limited to]:
-
-   - null-terminated strings may not be longer than 2G-1 bytes,
-     longer strings are treated as zero-length;
-   - dynamically and *internally* allocated chunks can't be larger
-     than 2G-1 bytes;
-   - inability to encrypt/decrypt chunks of data larger than 4GB
-     [it's possibly to *hash* chunks of arbitrary size through];
-
-   Neither of these is actually big deal and hardly encountered
-   in real-life applications.
-
- Compiling procedure
- -------------------
-
- You will need Perl. You can run under Cygwin or you can download
- ActiveState Perl from http://www.activestate.com/ActivePerl.
-
- You will need Microsoft Platform SDK, available for download at
- http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per
- April 2005 Platform SDK is equipped with Win64 compilers, as well
- as assemblers, but it might change in the future.
-
- To build for Win64/x64:
-
- > perl Configure VC-WIN64A
- > ms\do_win64a
- > nmake -f ms\ntdll.mak
- > cd out32dll
- > ..\ms\test
-
- To build for Win64/IA64:
-
- > perl Configure VC-WIN64I
- > ms\do_win64i
- > nmake -f ms\ntdll.mak
- > cd out32dll
- > ..\ms\test
-
- Naturally test-suite itself has to be executed on the target platform.
-
- Installation
- ------------
-
- TBD, for now see INSTALL.W32.
-
diff --git a/lib/libssl/src/INSTALL.WCE b/lib/libssl/src/INSTALL.WCE
deleted file mode 100644
index ac587d6bd26..00000000000
--- a/lib/libssl/src/INSTALL.WCE
+++ /dev/null
@@ -1,71 +0,0 @@
- 
- INSTALLATION FOR THE WINDOWS CE PLATFORM
- ----------------------------------------
-
- Building OpenSSL for Windows CE requires the following external tools:
-
-  * Microsoft eMbedded Visual C++ 3.0
-  * wcecompat compatibility library (www.essemer.com.au)
-  * Optionally ceutils for running automated tests (www.essemer.com.au)
-
- You also need Perl for Win32.  You will need ActiveState Perl, available
- from http://www.activestate.com/ActivePerl.
-
- Windows CE support in OpenSSL relies on wcecompat.  All Windows CE specific
- issues should be directed to www.essemer.com.au.
-
- The C Runtime Library implementation for Windows CE that is included with
- Microsoft eMbedded Visual C++ 3.0 is incomplete and in some places
- incorrect.  wcecompat plugs the holes and tries to bring the Windows CE
- CRT to a level that is more compatible with ANSI C.  wcecompat goes further
- and provides low-level IO and stream IO support for stdin/stdout/stderr
- (which Windows CE does not provide).  This IO functionality is not needed
- by the OpenSSL library itself but is used for the tests and openssl.exe.
- More information is available at www.essemer.com.au.
-
- Building
- --------
-
- Setup the eMbedded Visual C++ environment.  There are batch files for doing
- this installed with eVC++.  For an ARM processor, for example, execute:
-
- > "C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN\WCEARM.BAT"
-
- Next indicate where wcecompat is located:
-
- > set WCECOMPAT=C:\wcecompat
-
- Next you should run Configure:
-
- > perl Configure VC-CE
-
- Next you need to build the Makefiles:
-
- > ms\do_ms
-
- If you get errors about things not having numbers assigned then check the
- troubleshooting section in INSTALL.W32: you probably won't be able to compile
- it as it stands.
-
- Then from the VC++ environment at a prompt do:
-
- - to build static libraries:
-
-   > nmake -f ms\ce.mak
-
- - or to build DLLs:
-
-   > nmake -f ms\cedll.mak
-
- If all is well it should compile and you will have some static libraries and
- executables in out32, or some DLLs and executables in out32dll.  If you want
- to try the tests then make sure the ceutils are in the path and do:
- 
- > cd out32
- > ..\ms\testce
-
- This will copy each of the test programs to the Windows CE device and execute
- them, displaying the output of the tests on this computer.  The output should
- look similar to the output produced by running the tests for a regular Windows
- build.
-
diff --git a/lib/libssl/src/PROBLEMS b/lib/libssl/src/PROBLEMS
deleted file mode 100644
index 3eaab01f2ce..00000000000
--- a/lib/libssl/src/PROBLEMS
+++ /dev/null
@@ -1,213 +0,0 @@
-* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
-
-
-    NOTE: The problem described here only applies when OpenSSL isn't built
-    with shared library support (i.e. without the "shared" configuration
-    option).  If you build with shared library support, you will have no
-    problems as long as you set up DYLD_LIBRARY_PATH properly at all times.
-
-
-This is really a misfeature in ld, which seems to look for .dylib libraries
-along the whole library path before it bothers looking for .a libraries.  This
-means that -L switches won't matter unless OpenSSL is built with shared
-library support.
-
-The workaround may be to change the following lines in apps/Makefile and
-test/Makefile:
-
-  LIBCRYPTO=-L.. -lcrypto
-  LIBSSL=-L.. -lssl
-
-to:
-
-  LIBCRYPTO=../libcrypto.a
-  LIBSSL=../libssl.a
-
-It's possible that something similar is needed for shared library support
-as well.  That hasn't been well tested yet.
-
-
-Another solution that many seem to recommend is to move the libraries
-/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
-directory, build and install OpenSSL and anything that depends on your
-build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
-original places.  Note that the version numbers on those two libraries
-may differ on your machine.
-
-
-As long as Apple doesn't fix the problem with ld, this problem building
-OpenSSL will remain as is. Well, the problem was addressed in 0.9.8f by
-passing -Wl,-search_paths_first, but it's unknown if the flag was
-supported from the initial MacOS X release.
-
-
-* Parallell make leads to errors
-
-While running tests, running a parallell make is a bad idea.  Many test
-scripts use the same name for output and input files, which means different
-will interfere with each other and lead to test failure.
-
-The solution is simple for now: don't run parallell make when testing.
-
-
-* Bugs in gcc triggered
-
-- According to a problem report, there are bugs in gcc 3.0 that are
-  triggered by some of the code in OpenSSL, more specifically in
-  PEM_get_EVP_CIPHER_INFO().  The triggering code is the following:
-
-	header+=11;
-	if (*header != '4') return(0); header++;
-	if (*header != ',') return(0); header++;
-
-  What happens is that gcc might optimize a little too agressively, and
-  you end up with an extra incrementation when *header != '4'.
-
-  We recommend that you upgrade gcc to as high a 3.x version as you can.
-
-- According to multiple problem reports, some of our message digest
-  implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64
-  and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while
-  latter - SHA one.
-
-  The recomendation is to upgrade your compiler. This naturally applies to
-  other similar cases.
-
-- There is a subtle Solaris x86-specific gcc run-time environment bug, which
-  "falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug
-  manifests itself as Segmentation Fault upon early application start-up.
-  The problem can be worked around by patching the environment according to
-  http://www.openssl.org/~appro/values.c.
-
-* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
-
-As subject suggests SHA-1 might perform poorly (4 times slower)
-if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
-this seems to be the fact that compiler emits multiplication to
-perform shift operations:-( To work the problem around configure
-with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
-
-* Problems with hp-parisc2-cc target when used with "no-asm" flag
-
-When using the hp-parisc2-cc target, wrong bignum code is generated.
-This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
-aggressive optimization.
-The problem manifests itself by the BN_kronecker test hanging in an
-endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
-which itself hangs. The reason could be tracked down to the bn_mul_comba8()
-function in bn_asm.c. At some occasions the higher 32bit value of r[7]
-is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
-as no debugger support possible at +O3 and additional fprintf()'s
-introduced fixed the bug, therefore it is most likely a bug in the
-optimizer.
-The bug was found in the BN_kronecker test but may also lead to
-failures in other parts of the code.
-(See Ticket #426.)
-
-Workaround: modify the target to +O2 when building with no-asm.
-
-* Problems building shared libraries on SCO OpenServer Release 5.0.6
-  with gcc 2.95.3
-
-The symptoms appear when running the test suite, more specifically
-test/ectest, with the following result:
-
-OSSL_LIBPATH="`cd ..; pwd`"; LD_LIBRARY_PATH="$OSSL_LIBPATH:$LD_LIBRARY_PATH"; DYLD_LIBRARY_PATH="$OSSL_LIBPATH:$DYLD_LIBRARY_PATH"; SHLIB_PATH="$OSSL_LIBPATH:$SHLIB_PATH"; LIBPATH="$OSSL_LIBPATH:$LIBPATH"; if [ "debug-sco5-gcc" = "Cygwin" ]; then PATH="${LIBPATH}:$PATH"; fi; export LD_LIBRARY_PATH DYLD_LIBRARY_PATH SHLIB_PATH LIBPATH PATH; ./ectest
-ectest.c:186: ABORT
-
-The cause of the problem seems to be that isxdigit(), called from
-BN_hex2bn(), returns 0 on a perfectly legitimate hex digit.  Further
-investigation shows that any of the isxxx() macros return 0 on any
-input.  A direct look in the information array that the isxxx() use,
-called __ctype, shows that it contains all zeroes...
-
-Taking a look at the newly created libcrypto.so with nm, one can see
-that the variable __ctype is defined in libcrypto's .bss (which
-explains why it is filled with zeroes):
-
-$ nm -Pg libcrypto.so | grep __ctype
-__ctype B 0011659c
-__ctype2 U         
-
-Curiously, __ctype2 is undefined, in spite of being declared in
-/usr/include/ctype.h in exactly the same way as __ctype.
-
-Any information helping to solve this issue would be deeply
-appreciated.
-
-NOTE: building non-shared doesn't come with this problem.
-
-* ULTRIX build fails with shell errors, such as "bad substitution"
-  and "test: argument expected"
-
-The problem is caused by ULTRIX /bin/sh supporting only original
-Bourne shell syntax/semantics, and the trouble is that the vast
-majority is so accustomed to more modern syntax, that very few
-people [if any] would recognize the ancient syntax even as valid.
-This inevitably results in non-trivial scripts breaking on ULTRIX,
-and OpenSSL isn't an exclusion. Fortunately there is workaround,
-hire /bin/ksh to do the job /bin/sh fails to do.
-
-1. Trick make(1) to use /bin/ksh by setting up following environ-
-   ment variables *prior* you execute ./Configure and make:
-
-	PROG_ENV=POSIX
-	MAKESHELL=/bin/ksh
-	export PROG_ENV MAKESHELL
-
-   or if your shell is csh-compatible:
-
-	setenv PROG_ENV POSIX
-	setenv MAKESHELL /bin/ksh
-
-2. Trick /bin/sh to use alternative expression evaluator. Create
-   following 'test' script for example in /tmp:
-
-	#!/bin/ksh
-	${0##*/} "$@"
-
-   Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend*
-   your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter-
-   natively just replace system /bin/test and /bin/[ with the
-   above script.
-
-* hpux64-ia64-cc fails blowfish test.
-
-Compiler bug, presumably at particular patch level. It should be noted
-that same compiler generates correct 32-bit code, a.k.a. hpux-ia64-cc
-target. Drop optimization level to +O2 when compiling 64-bit bf_skey.o.
-
-* no-engines generates errors.
-
-Unfortunately, the 'no-engines' configuration option currently doesn't
-work properly.  Use 'no-hw' and you'll will at least get no hardware
-support.  We'll see how we fix that on OpenSSL versions past 0.9.8.
-
-* 'make test' fails in BN_sqr [commonly with "error 139" denoting SIGSEGV]
-  if elder GNU binutils were deployed to link shared libcrypto.so.
-
-As subject suggests the failure is caused by a bug in elder binutils,
-either as or ld, and was observed on FreeBSD and Linux. There are two
-options. First is naturally to upgrade binutils, the second one - to
-reconfigure with additional no-sse2 [or 386] option passed to ./config.
-
-* If configured with ./config no-dso, toolkit still gets linked with -ldl,
-  which most notably poses a problem when linking with dietlibc.
-
-We don't have framework to associate -ldl with no-dso, therefore the only
-way is to edit Makefile right after ./config no-dso and remove -ldl from
-EX_LIBS line.
-
-* hpux-parisc2-cc no-asm build fails with SEGV in ECDSA/DH.
-
-Compiler bug, presumably at particular patch level. Remaining
-hpux*-parisc*-cc configurations can be affected too. Drop optimization
-level to +O2 when compiling bn_nist.o.
-
-* solaris64-sparcv9-cc link failure
-
-Solaris 8 ar can fail to maintain symbol table in .a, which results in
-link failures. Apply 109147-09 or later or modify Makefile generated
-by ./Configure solaris64-sparcv9-cc and replace RANLIB assignment with
-
-	RANLIB= /usr/ccs/bin/ar rs