[Midnightbsd-cvs] src [7119] trunk/crypto/openssl: do some merge cleanup
laffer1 at midnightbsd.org
laffer1 at midnightbsd.org
Tue Jul 21 19:32:01 EDT 2015
Revision: 7119
http://svnweb.midnightbsd.org/src/?rev=7119
Author: laffer1
Date: 2015-07-21 19:32:00 -0400 (Tue, 21 Jul 2015)
Log Message:
-----------
do some merge cleanup
Modified Paths:
--------------
trunk/crypto/openssl/Makefile.org
trunk/crypto/openssl/apps/openssl.cnf
trunk/crypto/openssl/crypto/Makefile
trunk/crypto/openssl/crypto/opensslv.h
trunk/crypto/openssl/crypto/rand/rand_unix.c
trunk/crypto/openssl/doc/apps/ca.pod
trunk/crypto/openssl/doc/apps/config.pod
trunk/crypto/openssl/doc/apps/dgst.pod
trunk/crypto/openssl/doc/apps/x509.pod
trunk/crypto/openssl/doc/crypto/engine.pod
trunk/crypto/openssl/doc/ssl/SSL_CTX_set_psk_client_callback.pod
trunk/crypto/openssl/ssl/srtp.h
Added Paths:
-----------
trunk/crypto/openssl/util/mkrc.pl
Removed Paths:
-------------
trunk/crypto/openssl/INSTALL.DJGPP
trunk/crypto/openssl/INSTALL.MacOS
trunk/crypto/openssl/INSTALL.NW
trunk/crypto/openssl/INSTALL.OS2
trunk/crypto/openssl/INSTALL.VMS
trunk/crypto/openssl/INSTALL.W32
trunk/crypto/openssl/INSTALL.W64
trunk/crypto/openssl/INSTALL.WCE
trunk/crypto/openssl/demos/tunala/
trunk/crypto/openssl/demos/x509/
trunk/crypto/openssl/times/x86/
trunk/crypto/openssl/tools/
trunk/crypto/openssl/util/deltree.com
Deleted: trunk/crypto/openssl/INSTALL.DJGPP
===================================================================
--- trunk/crypto/openssl/INSTALL.DJGPP 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.DJGPP 2015-07-21 23:32:00 UTC (rev 7119)
@@ -1,47 +0,0 @@
-
-
- INSTALLATION ON THE DOS PLATFORM WITH DJGPP
- -------------------------------------------
-
- OpenSSL has been ported to DJGPP, a Unix look-alike 32-bit run-time
- environment for 16-bit 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 or
- directly at "http://www.delorie.com/pub/djgpp". For help on which
- files to download, see the DJGPP "ZIP PICKER" page at
- "http://www.delorie.com/djgpp/zip-picker.html". 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 the directory
- specified by the environment variable WATT_ROOT. If you have watt-32
- in directory "watt32" under your main DJGPP directory, specify
- WATT_ROOT="/dev/env/DJDIR/watt32".
-
- To compile OpenSSL, start your BASH shell, then configure for DJGPP by
- running "./Configure" with appropriate arguments:
-
- ./Configure no-threads --prefix=/dev/env/DJDIR DJGPP
-
- And finally fire up "make". 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.
-
- RUN-TIME CAVEAT LECTOR
- --------------
-
- Quoting FAQ:
-
- "Cryptographic software needs a source of unpredictable data to work
- correctly. Many open source operating systems provide a "randomness
- device" (/dev/urandom or /dev/random) that serves this purpose."
-
- As of version 0.9.7f DJGPP port checks upon /dev/urandom$ for a 3rd
- party "randomness" DOS driver. One such driver, NOISE.SYS, can be
- obtained from "http://www.rahul.net/dkaufman/index.html".
Deleted: trunk/crypto/openssl/INSTALL.MacOS
===================================================================
--- trunk/crypto/openssl/INSTALL.MacOS 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.MacOS 2015-07-21 23:32:00 UTC (rev 7119)
@@ -1,72 +0,0 @@
-OpenSSL - Port To The Macintosh OS 9 or Earlier
-===============================================
-
-Thanks to Roy Wood <roy at 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 at centricsystems.ca
-
--Roy Wood"
-
Deleted: trunk/crypto/openssl/INSTALL.NW
===================================================================
--- trunk/crypto/openssl/INSTALL.NW 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.NW 2015-07-21 23:32:00 UTC (rev 7119)
@@ -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".
-
Deleted: trunk/crypto/openssl/INSTALL.OS2
===================================================================
--- trunk/crypto/openssl/INSTALL.OS2 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.OS2 2015-07-21 23:32:00 UTC (rev 7119)
@@ -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.
Deleted: trunk/crypto/openssl/INSTALL.VMS
===================================================================
--- trunk/crypto/openssl/INSTALL.VMS 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.VMS 2015-07-21 23:32:00 UTC (rev 7119)
@@ -1,293 +0,0 @@
- VMS Installation instructions
- written by Richard Levitte
- <richard at 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 at 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 at 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 at openssl.org> or to me directly if you
-have any ideas.
-
---
-Richard Levitte <richard at levitte.org>
-2000-02-27, 2011-03-18
Deleted: trunk/crypto/openssl/INSTALL.W32
===================================================================
--- trunk/crypto/openssl/INSTALL.W32 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.W32 2015-07-21 23:32:00 UTC (rev 7119)
@@ -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.
Deleted: trunk/crypto/openssl/INSTALL.W64
===================================================================
--- trunk/crypto/openssl/INSTALL.W64 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.W64 2015-07-21 23:32:00 UTC (rev 7119)
@@ -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.
-
Deleted: trunk/crypto/openssl/INSTALL.WCE
===================================================================
--- trunk/crypto/openssl/INSTALL.WCE 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/INSTALL.WCE 2015-07-21 23:32:00 UTC (rev 7119)
@@ -1,95 +0,0 @@
-
- INSTALLATION FOR THE WINDOWS CE PLATFORM
- ----------------------------------------
-
- Building OpenSSL for Windows CE requires the following external tools:
-
- * Microsoft eMbedded Visual C++ 3.0 or later
- * Appropriate SDK might be required
- * Perl for Win32 [commonly recommended ActiveState Perl is available
- from http://www.activestate.com/Products/ActivePerl/]
-
- * wcecompat compatibility library available at
- http://www.essemer.com.au/windowsce/
- * Optionally ceutils for running automated tests (same location)
-
- _or_
-
- * PocketConsole driver and PortSDK available at
- http://www.symbolictools.de/public/pocketconsole/
- * CMD command interpreter (same location)
-
- As Windows CE support in OpenSSL relies on 3rd party compatibility
- library, it's appropriate to check corresponding URL for updates. For
- example if you choose wcecompat, note that as for the moment of this
- writing version 1.2 is available and actually required for WCE 4.2
- and newer platforms. All wcecompat issues should be directed to
- www.essemer.com.au.
-
- Why compatibility library at all? The C Runtime Library implementation
- for Windows CE that is included with Microsoft eMbedded Visual C++ is
- incomplete and in some places incorrect. Compatibility library plugs
- the holes and tries to bring the Windows CE CRT to [more] usable level.
- Most gaping hole in CRT is support for stdin/stdout/stderr IO, which
- proposed compatibility libraries solve in two different ways: wcecompat
- redirects IO to active sync link, while PortSDK - to NT-like console
- driver on the handheld itself.
-
- 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 pick compatibility library according to your preferences.
-
- 1. To choose wcecompat set up WCECOMPAT environment variable pointing
- at the location of wcecompat tree "root":
-
- > set WCECOMPAT=C:\wcecompat
- > set PORTSDK_LIBPATH=
-
- 2. To choose PortSDK set up PORTSDK_LIBPATH to point at hardware-
- specific location where your portlib.lib is installed:
-
- > set PORTSDK_LIBPATH=C:\PortSDK\lib\ARM
- > set WCECOMPAT=
-
- Note that you may not set both variables.
-
- 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:
-
- > nmake -f ms\cedll.mak
-
- [note that static builds are not supported under CE]
-
- If all is well it should compile and you will have some DLLs and executables
- in out32dll*.
-
- <<< everyting below needs revision in respect to wcecompat vs. PortSDK >>>
-
- 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.
-
Modified: trunk/crypto/openssl/Makefile.org
===================================================================
--- trunk/crypto/openssl/Makefile.org 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/Makefile.org 2015-07-21 23:32:00 UTC (rev 7119)
@@ -63,8 +63,8 @@
PEX_LIBS=
EX_LIBS=
EXE_EXT=
-ARFLAGS=
-AR=ar $(ARFLAGS) r
+ARFLAGS?= r
+AR=ar $(ARFLAGS)
RANLIB= ranlib
NM= nm
PERL= perl
Modified: trunk/crypto/openssl/apps/openssl.cnf
===================================================================
--- trunk/crypto/openssl/apps/openssl.cnf 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/apps/openssl.cnf 2015-07-21 23:32:00 UTC (rev 7119)
@@ -1,3 +1,4 @@
+# $FreeBSD: stable/10/crypto/openssl/apps/openssl.cnf 238405 2012-07-12 19:30:53Z jkim $
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
Modified: trunk/crypto/openssl/crypto/Makefile
===================================================================
--- trunk/crypto/openssl/crypto/Makefile 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/crypto/Makefile 2015-07-21 23:32:00 UTC (rev 7119)
@@ -13,7 +13,8 @@
MAKEDEPEND= $(TOP)/util/domd $(TOP) -MD $(MAKEDEPPROG)
MAKEFILE= Makefile
RM= rm -f
-AR= ar r
+ARFLAGS?= r
+AR= ar ${ARFLAGS}
RECURSIVE_MAKE= [ -n "$(SDIRS)" ] && for i in $(SDIRS) ; do \
(cd $$i && echo "making $$target in $(DIR)/$$i..." && \
Modified: trunk/crypto/openssl/crypto/opensslv.h
===================================================================
--- trunk/crypto/openssl/crypto/opensslv.h 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/crypto/opensslv.h 2015-07-21 23:32:00 UTC (rev 7119)
@@ -34,7 +34,7 @@
# ifdef OPENSSL_FIPS
# define OPENSSL_VERSION_TEXT "OpenSSL 1.0.1o-fips 12 Jun 2015"
# else
-# define OPENSSL_VERSION_TEXT "OpenSSL 1.0.1o 12 Jun 2015"
+# define OPENSSL_VERSION_TEXT "OpenSSL 1.0.1o-freebsd 12 Jun 2015"
# endif
# define OPENSSL_VERSION_PTEXT " part of " OPENSSL_VERSION_TEXT
@@ -88,7 +88,7 @@
* should only keep the versions that are binary compatible with the current.
*/
# define SHLIB_VERSION_HISTORY ""
-# define SHLIB_VERSION_NUMBER "1.0.0"
+# define SHLIB_VERSION_NUMBER "7"
#ifdef __cplusplus
Modified: trunk/crypto/openssl/crypto/rand/rand_unix.c
===================================================================
--- trunk/crypto/openssl/crypto/rand/rand_unix.c 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/crypto/rand/rand_unix.c 2015-07-21 23:32:00 UTC (rev 7119)
@@ -222,7 +222,7 @@
}
return 1;
}
-# elif defined __OpenBSD__
+# elif defined(__FreeBSD__) || defined(__OpenBSD__)
int RAND_poll(void)
{
u_int32_t rnd = 0, i;
@@ -239,7 +239,8 @@
return 1;
}
-# else /* !defined(__OpenBSD__) */
+# else /* !(defined(__FreeBSD__) ||
+ * defined(__OpenBSD__)) */
int RAND_poll(void)
{
unsigned long l;
@@ -431,7 +432,8 @@
# endif
}
-# endif /* defined(__OpenBSD__) */
+# endif /* defined(__FreeBSD__) ||
+ * defined(__OpenBSD__) */
#endif /* !(defined(OPENSSL_SYS_WINDOWS) ||
* defined(OPENSSL_SYS_WIN32) ||
* defined(OPENSSL_SYS_VMS) ||
Modified: trunk/crypto/openssl/doc/apps/ca.pod
===================================================================
--- trunk/crypto/openssl/doc/apps/ca.pod 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/doc/apps/ca.pod 2015-07-21 23:32:00 UTC (rev 7119)
@@ -91,7 +91,7 @@
=item B<-infiles>
if present this should be the last option, all subsequent arguments
-are assumed to the the names of files containing certificate requests.
+are assumed to be the names of files containing certificate requests.
=item B<-out filename>
Modified: trunk/crypto/openssl/doc/apps/config.pod
===================================================================
--- trunk/crypto/openssl/doc/apps/config.pod 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/doc/apps/config.pod 2015-07-21 23:32:00 UTC (rev 7119)
@@ -264,7 +264,7 @@
Suppose you want a variable called B<tmpfile> to refer to a
temporary filename. The directory it is placed in can determined by
-the the B<TEMP> or B<TMP> environment variables but they may not be
+the B<TEMP> or B<TMP> environment variables but they may not be
set to any value at all. If you just include the environment variable
names and the variable doesn't exist then this will cause an error when
an attempt is made to load the configuration file. By making use of the
Modified: trunk/crypto/openssl/doc/apps/dgst.pod
===================================================================
--- trunk/crypto/openssl/doc/apps/dgst.pod 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/doc/apps/dgst.pod 2015-07-21 23:32:00 UTC (rev 7119)
@@ -105,12 +105,12 @@
=item B<-verify filename>
-verify the signature using the the public key in "filename".
+verify the signature using the public key in "filename".
The output is either "Verification OK" or "Verification Failure".
=item B<-prverify filename>
-verify the signature using the the private key in "filename".
+verify the signature using the private key in "filename".
=item B<-signature filename>
Modified: trunk/crypto/openssl/doc/apps/x509.pod
===================================================================
--- trunk/crypto/openssl/doc/apps/x509.pod 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/doc/apps/x509.pod 2015-07-21 23:32:00 UTC (rev 7119)
@@ -142,7 +142,7 @@
=item B<-pubkey>
-outputs the the certificate's SubjectPublicKeyInfo block in PEM format.
+outputs the certificate's SubjectPublicKeyInfo block in PEM format.
=item B<-modulus>
Modified: trunk/crypto/openssl/doc/crypto/engine.pod
===================================================================
--- trunk/crypto/openssl/doc/crypto/engine.pod 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/doc/crypto/engine.pod 2015-07-21 23:32:00 UTC (rev 7119)
@@ -517,7 +517,7 @@
this symbol is considered a "generic" command is handled directly by the
OpenSSL core routines.
-It is using these "core" control commands that one can discover the the control
+It is using these "core" control commands that one can discover the control
commands implemented by a given ENGINE, specifically the commands;
#define ENGINE_HAS_CTRL_FUNCTION 10
Modified: trunk/crypto/openssl/doc/ssl/SSL_CTX_set_psk_client_callback.pod
===================================================================
--- trunk/crypto/openssl/doc/ssl/SSL_CTX_set_psk_client_callback.pod 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/doc/ssl/SSL_CTX_set_psk_client_callback.pod 2015-07-21 23:32:00 UTC (rev 7119)
@@ -59,7 +59,7 @@
or SSL_set_psk_client_callback(). The callback function is given the
connection in parameter B<ssl>, a B<NULL>-terminated PSK identity hint
sent by the server in parameter B<hint>, a buffer B<identity> of
-length B<max_identity_len> bytes where the the resulting
+length B<max_identity_len> bytes where the resulting
B<NULL>-terminated identity is to be stored, and a buffer B<psk> of
length B<max_psk_len> bytes where the resulting pre-shared key is to
be stored.
Modified: trunk/crypto/openssl/ssl/srtp.h
===================================================================
--- trunk/crypto/openssl/ssl/srtp.h 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/ssl/srtp.h 2015-07-21 23:32:00 UTC (rev 7119)
@@ -137,7 +137,6 @@
SRTP_PROTECTION_PROFILE *SSL_get_selected_srtp_profile(SSL *s);
STACK_OF(SRTP_PROTECTION_PROFILE) *SSL_get_srtp_profiles(SSL *ssl);
-SRTP_PROTECTION_PROFILE *SSL_get_selected_srtp_profile(SSL *s);
# endif
Deleted: trunk/crypto/openssl/util/deltree.com
===================================================================
--- trunk/crypto/openssl/util/deltree.com 2015-07-21 23:23:45 UTC (rev 7118)
+++ trunk/crypto/openssl/util/deltree.com 2015-07-21 23:32:00 UTC (rev 7119)
@@ -1,34 +0,0 @@
-$! DELTREE.COM
-$
-$ call deltree 'p1'
-$ exit $status
-$
-$ deltree: subroutine ! P1 is a name of a directory
-$ on control_y then goto dt_STOP
-$ on warning then goto dt_exit
-$ _dt_def = f$trnlnm("SYS$DISK")+f$directory()
-$ if f$parse(p1) .eqs. "" then exit
-$ set default 'f$parse(p1,,,"DEVICE")''f$parse(p1,,,"DIRECTORY")'
-$ p1 = f$parse(p1,,,"NAME") + f$parse(p1,,,"TYPE")
-$ _fp = f$parse(".DIR",p1)
-$ dt_loop:
-$ _f = f$search(_fp)
-$ if _f .eqs. "" then goto dt_loopend
-$ call deltree [.'f$parse(_f,,,"NAME")']*.*
-$ goto dt_loop
-$ dt_loopend:
-$ _fp = f$parse(p1,".;*")
-$ if f$search(_fp) .eqs. "" then goto dt_exit
-$ set noon
-$ set file/prot=(S:RWED,O:RWED,G:RWED,W:RWED) '_fp'
-$ set on
-$ delete/nolog '_fp'
-$ dt_exit:
-$ set default '_dt_def'
-$ goto dt_end
-$ dt_STOP:
-$ set default '_dt_def'
-$ stop/id=""
-$ exit
-$ dt_end:
-$ endsubroutine
Added: trunk/crypto/openssl/util/mkrc.pl
===================================================================
--- trunk/crypto/openssl/util/mkrc.pl (rev 0)
+++ trunk/crypto/openssl/util/mkrc.pl 2015-07-21 23:32:00 UTC (rev 7119)
@@ -0,0 +1,71 @@
+#!/bin/env perl
+#
+open FD,"crypto/opensslv.h";
+while(<FD>) {
+ if (/OPENSSL_VERSION_NUMBER\s+(0x[0-9a-f]+)/i) {
+ $ver = hex($1);
+ $v1 = ($ver>>28);
+ $v2 = ($ver>>20)&0xff;
+ $v3 = ($ver>>12)&0xff;
+ $v4 = ($ver>> 4)&0xff;
+ $beta = $ver&0xf;
+ $version = "$v1.$v2.$v3";
+ if ($beta==0xf) { $version .= chr(ord('a')+$v4-1) if ($v4); }
+ elsif ($beta==0){ $version .= "-dev"; }
+ else { $version .= "-beta$beta"; }
+ last;
+ }
+}
+close(FD);
+
+$filename = $ARGV[0]; $filename =~ /(.*)\.([^.]+)$/;
+$basename = $1;
+$extname = $2;
+
+if ($extname =~ /dll/i) { $description = "OpenSSL shared library"; }
+else { $description = "OpenSSL application"; }
+
+print <<___;
+#include <winver.h>
+
+LANGUAGE 0x09,0x01
+
+1 VERSIONINFO
+ FILEVERSION $v1,$v2,$v3,$v4
+ PRODUCTVERSION $v1,$v2,$v3,$v4
+ FILEFLAGSMASK 0x3fL
+#ifdef _DEBUG
+ FILEFLAGS 0x01L
+#else
+ FILEFLAGS 0x00L
+#endif
+ FILEOS VOS__WINDOWS32
+ FILETYPE VFT_DLL
+ FILESUBTYPE 0x0L
+BEGIN
+ BLOCK "StringFileInfo"
+ BEGIN
+ BLOCK "040904b0"
+ BEGIN
+ // Required:
+ VALUE "CompanyName", "The OpenSSL Project, http://www.openssl.org/\\0"
+ VALUE "FileDescription", "$description\\0"
+ VALUE "FileVersion", "$version\\0"
+ VALUE "InternalName", "$basename\\0"
+ VALUE "OriginalFilename", "$filename\\0"
+ VALUE "ProductName", "The OpenSSL Toolkit\\0"
+ VALUE "ProductVersion", "$version\\0"
+ // Optional:
+ //VALUE "Comments", "\\0"
+ VALUE "LegalCopyright", "Copyright \xA9 1998-2006 The OpenSSL Project. Copyright \xA9 1995-1998 Eric A. Young, Tim J. Hudson. All rights reserved.\\0"
+ //VALUE "LegalTrademarks", "\\0"
+ //VALUE "PrivateBuild", "\\0"
+ //VALUE "SpecialBuild", "\\0"
+ END
+ END
+ BLOCK "VarFileInfo"
+ BEGIN
+ VALUE "Translation", 0x409, 0x4b0
+ END
+END
+___
Property changes on: trunk/crypto/openssl/util/mkrc.pl
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:keywords
## -0,0 +1 ##
+MidnightBSD=%H
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
More information about the Midnightbsd-cvs
mailing list