summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorderaadt <>2014-04-13 16:13:01 +0000
committerderaadt <>2014-04-13 16:13:01 +0000
commit42a3d72487e3ff2ad08effaf3b6f42406ef1f20a (patch)
tree729bb5a71315799ccb61de94babb811d42fb7176
parent1a68679d06736eb89f8f57f71805187c5389270f (diff)
downloadopenbsd-42a3d72487e3ff2ad08effaf3b6f42406ef1f20a.tar.gz
openbsd-42a3d72487e3ff2ad08effaf3b6f42406ef1f20a.tar.bz2
openbsd-42a3d72487e3ff2ad08effaf3b6f42406ef1f20a.zip
Irrelevant.
Diffstat
-rw-r--r--src/lib/libssl/src/INSTALL7
-rw-r--r--src/lib/libssl/src/INSTALL.DJGPP47
-rw-r--r--src/lib/libssl/src/INSTALL.MacOS72
-rw-r--r--src/lib/libssl/src/INSTALL.NW454
-rw-r--r--src/lib/libssl/src/INSTALL.OS231
-rw-r--r--src/lib/libssl/src/INSTALL.VMS293
-rw-r--r--src/lib/libssl/src/INSTALL.W32325
-rw-r--r--src/lib/libssl/src/INSTALL.W6466
-rw-r--r--src/lib/libssl/src/INSTALL.WCE95
-rw-r--r--src/lib/libssl/src/PROBLEMS213
10 files changed, 0 insertions, 1603 deletions
diff --git a/src/lib/libssl/src/INSTALL b/src/lib/libssl/src/INSTALL
index 1325079f2a..bd37bf52d2 100644
--- a/src/lib/libssl/src/INSTALL
+++ b/src/lib/libssl/src/INSTALL
@@ -2,13 +2,6 @@
2 INSTALLATION ON THE UNIX PLATFORM 2 INSTALLATION ON THE UNIX PLATFORM
3 --------------------------------- 3 ---------------------------------
4 4
5 [Installation on DOS (with djgpp), Windows, OpenVMS, MacOS (before MacOS X)
6 and NetWare is described in INSTALL.DJGPP, INSTALL.W32, INSTALL.VMS,
7 INSTALL.MacOS and INSTALL.NW.
8
9 This document describes installation on operating systems in the Unix
10 family.]
11
12 To install OpenSSL, you will need: 5 To install OpenSSL, you will need:
13 6
14 * make 7 * make
diff --git a/src/lib/libssl/src/INSTALL.DJGPP b/src/lib/libssl/src/INSTALL.DJGPP
deleted file mode 100644
index 1047ec90a5..0000000000
--- a/src/lib/libssl/src/INSTALL.DJGPP
+++ /dev/null
@@ -1,47 +0,0 @@
1
2
3 INSTALLATION ON THE DOS PLATFORM WITH DJGPP
4 -------------------------------------------
5
6 OpenSSL has been ported to DJGPP, a Unix look-alike 32-bit run-time
7 environment for 16-bit DOS, but only with long filename support.
8 If you wish to compile on native DOS with 8+3 filenames, you will
9 have to tweak the installation yourself, including renaming files
10 with illegal or duplicate names.
11
12 You should have a full DJGPP environment installed, including the
13 latest versions of DJGPP, GCC, BINUTILS, BASH, etc. This package
14 requires that PERL and BC also be installed.
15
16 All of these can be obtained from the usual DJGPP mirror sites or
17 directly at "http://www.delorie.com/pub/djgpp". For help on which
18 files to download, see the DJGPP "ZIP PICKER" page at
19 "http://www.delorie.com/djgpp/zip-picker.html". You also need to have
20 the WATT-32 networking package installed before you try to compile
21 OpenSSL. This can be obtained from "http://www.bgnett.no/~giva/".
22 The Makefile assumes that the WATT-32 code is in the directory
23 specified by the environment variable WATT_ROOT. If you have watt-32
24 in directory "watt32" under your main DJGPP directory, specify
25 WATT_ROOT="/dev/env/DJDIR/watt32".
26
27 To compile OpenSSL, start your BASH shell, then configure for DJGPP by
28 running "./Configure" with appropriate arguments:
29
30 ./Configure no-threads --prefix=/dev/env/DJDIR DJGPP
31
32 And finally fire up "make". You may run out of DPMI selectors when
33 running in a DOS box under Windows. If so, just close the BASH
34 shell, go back to Windows, and restart BASH. Then run "make" again.
35
36 RUN-TIME CAVEAT LECTOR
37 --------------
38
39 Quoting FAQ:
40
41 "Cryptographic software needs a source of unpredictable data to work
42 correctly. Many open source operating systems provide a "randomness
43 device" (/dev/urandom or /dev/random) that serves this purpose."
44
45 As of version 0.9.7f DJGPP port checks upon /dev/urandom$ for a 3rd
46 party "randomness" DOS driver. One such driver, NOISE.SYS, can be
47 obtained from "http://www.rahul.net/dkaufman/index.html".
diff --git a/src/lib/libssl/src/INSTALL.MacOS b/src/lib/libssl/src/INSTALL.MacOS
deleted file mode 100644
index 01c60d81f9..0000000000
--- a/src/lib/libssl/src/INSTALL.MacOS
+++ /dev/null
@@ -1,72 +0,0 @@
1OpenSSL - Port To The Macintosh OS 9 or Earlier
2===============================================
3
4Thanks to Roy Wood <roy@centricsystems.ca> initial support for Mac OS (pre
5X) is now provided. "Initial" means that unlike other platforms where you
6get an SDK and a "swiss army" openssl application, on Macintosh you only
7get one sample application which fetches a page over HTTPS(*) and dumps it
8in a window. We don't even build the test applications so that we can't
9guarantee that all algorithms are operational.
10
11Required software:
12
13- StuffIt Expander 5.5 or later, alternatively MacGzip and SUNtar;
14- Scriptable Finder;
15- CodeWarrior Pro 5;
16
17Installation procedure:
18
19- fetch the source at ftp://ftp.openssl.org/ (well, you probably already
20 did, huh?)
21- unpack the .tar.gz file:
22 - if you have StuffIt Expander then just drag it over it;
23 - otherwise uncompress it with MacGzip and then unpack with SUNtar;
24- locate MacOS folder in OpenSSL source tree and open it;
25- unbinhex mklinks.as.hqx and OpenSSL.mcp.hqx if present (**), do it
26 "in-place", i.e. unpacked files should end-up in the very same folder;
27- execute mklinks.as;
28- open OpenSSL.mcp(***) and build 'GetHTTPS PPC' target(****);
29- that's it for now;
30
31(*) URL is hardcoded into ./MacOS/GetHTTPS.src/GetHTTPS.cpp, lines 40
32 to 42, change appropriately.
33(**) If you use SUNtar, then it might have already unbinhexed the files
34 in question.
35(***) The project file was saved with CW Pro 5.3. If you have an earlier
36 version and it refuses to open it, then download
37 http://www.openssl.org/~appro/OpenSSL.mcp.xml and import it
38 overwriting the original OpenSSL.mcp.
39(****) Other targets are works in progress. If you feel like giving 'em a
40 shot, then you should know that OpenSSL* and Lib* targets are
41 supposed to be built with the GUSI, MacOS library which mimics
42 BSD sockets and some other POSIX APIs. The GUSI distribution is
43 expected to be found in the same directory as the openssl source tree,
44 i.e., in the parent directory to the one where this very file,
45 namely INSTALL.MacOS, resides. For more information about GUSI, see
46 http://www.iis.ee.ethz.ch/~neeri/macintosh/gusi-qa.html
47
48Finally some essential comments from our generous contributor:-)
49
50"I've gotten OpenSSL working on the Macintosh. It's probably a bit of a
51hack, but it works for what I'm doing. If you don't like the way I've done
52it, then feel free to change what I've done. I freely admit that I've done
53some less-than-ideal things in my port, and if you don't like the way I've
54done something, then feel free to change it-- I won't be offended!
55
56... I've tweaked "bss_sock.c" a little to call routines in a "MacSocket"
57library I wrote. My MacSocket library is a wrapper around OpenTransport,
58handling stuff like endpoint creation, reading, writing, etc. It is not
59designed as a high-performance package such as you'd use in a webserver,
60but is fine for lots of other applications. MacSocket also uses some other
61code libraries I've written to deal with string manipulations and error
62handling. Feel free to use these things in your own code, but give me
63credit and/or send me free stuff in appreciation! :-)
64
65...
66
67If you have any questions, feel free to email me as the following:
68
69roy@centricsystems.ca
70
71-Roy Wood"
72
diff --git a/src/lib/libssl/src/INSTALL.NW b/src/lib/libssl/src/INSTALL.NW
deleted file mode 100644
index 609a7309e1..0000000000
--- a/src/lib/libssl/src/INSTALL.NW
+++ /dev/null
@@ -1,454 +0,0 @@
1
2INSTALLATION ON THE NETWARE PLATFORM
3------------------------------------
4
5Notes about building OpenSSL for NetWare.
6
7
8BUILD PLATFORM:
9---------------
10The build scripts (batch files, perl scripts, etc) have been developed and
11tested on W2K. The scripts should run fine on other Windows platforms
12(NT, Win9x, WinXP) but they have not been tested. They may require some
13modifications.
14
15
16Supported NetWare Platforms - NetWare 5.x, NetWare 6.x:
17-------------------------------------------------------
18OpenSSL can either use the WinSock interfaces introduced in NetWare 5,
19or the BSD socket interface. Previous versions of NetWare, 4.x and 3.x,
20are only supported if OpenSSL is build for CLIB and BSD sockets;
21WinSock builds only support NetWare 5 and up.
22
23On NetWare there are two c-runtime libraries. There is the legacy CLIB
24interfaces and the newer LIBC interfaces. Being ANSI-C libraries, the
25functionality in CLIB and LIBC is similar but the LIBC interfaces are built
26using Novell Kernal Services (NKS) which is designed to leverage
27multi-processor environments.
28
29The NetWare port of OpenSSL can be configured to build using CLIB or LIBC.
30The CLIB build was developed and tested using NetWare 5.0 sp6.0a. The LIBC
31build was developed and tested using the NetWare 6.0 FCS.
32
33The necessary LIBC functionality ships with NetWare 6. However, earlier
34NetWare 5.x versions will require updates in order to run the OpenSSL LIBC
35build (NetWare 5.1 SP8 is known to work).
36
37As of June 2005, the LIBC build can be configured to use BSD sockets instead
38of WinSock sockets. Call Configure (usually through netware\build.bat) using
39a target of "netware-libc-bsdsock" instead of "netware-libc".
40
41As of June 2007, support for CLIB and BSD sockets is also now available
42using a target of "netware-clib-bsdsock" instead of "netware-clib";
43also gcc builds are now supported on both Linux and Win32 (post 0.9.8e).
44
45REQUIRED TOOLS:
46---------------
47Based upon the configuration and build options used, some or all of the
48following tools may be required:
49
50* Perl for Win32 - required (http://www.activestate.com/ActivePerl)
51 Used to run the various perl scripts on the build platform.
52
53* Perl 5.8.0 for NetWare v3.20 (or later) - required
54 (http://developer.novell.com) Used to run the test script on NetWare
55 after building.
56
57* Compiler / Linker - required:
58 Metrowerks CodeWarrior PDK 2.1 (or later) for NetWare (commercial):
59 Provides command line tools used for building.
60 Tools:
61 mwccnlm.exe - C/C++ Compiler for NetWare
62 mwldnlm.exe - Linker for NetWare
63 mwasmnlm.exe - x86 assembler for NetWare (if using assembly option)
64
65 gcc / nlmconv Cross-Compiler, available from Novell Forge (free):
66 http://forge.novell.com/modules/xfmod/project/?aunixnw
67
68* Assemblers - optional:
69 If you intend to build using the assembly options you will need an
70 assembler. Work has been completed to support two assemblers, Metrowerks
71 and NASM. However, during development, a bug was found in the Metrowerks
72 assembler which generates incorrect code. Until this problem is fixed,
73 the Metrowerks assembler cannot be used.
74
75 mwasmnlm.exe - Metrowerks x86 assembler - part of CodeWarrior tools.
76 (version 2.2 Built Aug 23, 1999 - not useable due to code
77 generation bug)
78
79 nasmw.exe - Netwide Assembler NASM
80 version 0.98 was used in development and testing
81
82* Make Tool - required:
83 In order to build you will need a make tool. Two make tools are
84 supported, GNU make (gmake.exe) or Microsoft nmake.exe.
85
86 make.exe - GNU make for Windows (version 3.75 used for development)
87 http://gnuwin32.sourceforge.net/packages/make.htm
88
89 nmake.exe - Microsoft make (Version 6.00.8168.0 used for development)
90 http://support.microsoft.com/kb/132084/EN-US/
91
92* Novell Developer Kit (NDK) - required: (http://developer.novell.com)
93
94 CLIB - BUILDS:
95
96 WinSock2 Developer Components for NetWare:
97 For initial development, the October 27, 2000 version was used.
98 However, future versions should also work.
99
100 NOTE: The WinSock2 components include headers & import files for
101 NetWare, but you will also need the winsock2.h and supporting
102 headers (pshpack4.h, poppack.h, qos.h) delivered in the
103 Microsoft SDK. Note: The winsock2.h support headers may change
104 with various versions of winsock2.h. Check the dependencies
105 section on the NDK WinSock2 download page for the latest
106 information on dependencies. These components are unsupported by
107 Novell. They are provided as a courtesy, but it is strongly
108 suggested that all development be done using LIBC, not CLIB.
109
110 As of June 2005, the WinSock2 components are available at:
111 http://forgeftp.novell.com//ws2comp/
112
113
114 NLM and NetWare libraries for C (including CLIB and XPlat):
115 If you are going to build a CLIB version of OpenSSL, you will
116 need the CLIB headers and imports. The March, 2001 NDK release or
117 later is recommended.
118
119 Earlier versions should work but haven't been tested. In recent
120 versions the import files have been consolidated and function
121 names moved. This means you may run into link problems
122 (undefined symbols) when using earlier versions. The functions
123 are available in earlier versions, but you will have to modifiy
124 the make files to include additional import files (see
125 openssl\util\pl\netware.pl).
126
127
128 LIBC - BUILDS:
129
130 Libraries for C (LIBC) - LIBC headers and import files
131 If you are going to build a LIBC version of OpenSSL, you will
132 need the LIBC headers and imports. The March 14, 2002 NDK release or
133 later is required.
134
135 NOTE: The LIBC SDK includes the necessary WinSock2 support.
136 It is not necessary to download the WinSock2 NDK when building for
137 LIBC. The LIBC SDK also includes the appropriate BSD socket support
138 if configuring to use BSD sockets.
139
140
141BUILDING:
142---------
143Before building, you will need to set a few environment variables. You can
144set them manually or you can modify the "netware\set_env.bat" file.
145
146The set_env.bat file is a template you can use to set up the path
147and environment variables you will need to build. Modify the
148various lines to point to YOUR tools and run set_env.bat.
149
150 netware\set_env.bat <target> [compiler]
151
152 target - "netware-clib" - CLIB NetWare build
153 - "netware-libc" - LIBC NetWare build
154
155 compiler - "gnuc" - GNU GCC Compiler
156 - "codewarrior" - MetroWerks CodeWarrior (default)
157
158If you don't use set_env.bat, you will need to set up the following
159environment variables:
160
161 PATH - Set PATH to point to the tools you will use.
162
163 INCLUDE - The location of the NDK include files.
164
165 CLIB ex: set INCLUDE=c:\ndk\nwsdk\include\nlm
166 LIBC ex: set INCLUDE=c:\ndk\libc\include
167
168 PRELUDE - The absolute path of the prelude object to link with. For
169 a CLIB build it is recommended you use the "clibpre.o" files shipped
170 with the Metrowerks PDK for NetWare. For a LIBC build you should
171 use the "libcpre.o" file delivered with the LIBC NDK components.
172
173 CLIB ex: set PRELUDE=c:\ndk\nwsdk\imports\clibpre.o
174 LIBC ex: set PRELUDE=c:\ndk\libc\imports\libcpre.o
175
176 IMPORTS - The locaton of the NDK import files.
177
178 CLIB ex: set IMPORTS=c:\ndk\nwsdk\imports
179 LIBC ex: set IMPORTS=c:\ndk\libc\imports
180
181
182In order to build, you need to run the Perl scripts to configure the build
183process and generate a make file. There is a batch file,
184"netware\build.bat", to automate the process.
185
186Build.bat runs the build configuration scripts and generates a make file.
187If an assembly option is specified, it also runs the scripts to generate
188the assembly code. Always run build.bat from the "openssl" directory.
189
190 netware\build [target] [debug opts] [assembly opts] [configure opts]
191
192 target - "netware-clib" - CLIB NetWare build (WinSock Sockets)
193 - "netware-clib-bsdsock" - CLIB NetWare build (BSD Sockets)
194 - "netware-libc" - LIBC NetWare build (WinSock Sockets)
195 - "netware-libc-bsdsock" - LIBC NetWare build (BSD Sockets)
196
197 debug opts - "debug" - build debug
198
199 assembly opts - "nw-mwasm" - use Metrowerks assembler
200 "nw-nasm" - use NASM assembler
201 "no-asm" - don't use assembly
202
203 configure opts- all unrecognized arguments are passed to the
204 perl 'configure' script. See that script for
205 internal documentation regarding options that
206 are available.
207
208 examples:
209
210 CLIB build, debug, without assembly:
211 netware\build.bat netware-clib debug no-asm
212
213 LIBC build, non-debug, using NASM assembly, add mdc2 support:
214 netware\build.bat netware-libc nw-nasm enable-mdc2
215
216 LIBC build, BSD sockets, non-debug, without assembly:
217 netware\build.bat netware-libc-bsdsock no-asm
218
219Running build.bat generates a make file to be processed by your make
220tool (gmake or nmake):
221
222 CLIB ex: gmake -f netware\nlm_clib_dbg.mak
223 LIBC ex: gmake -f netware\nlm_libc.mak
224 LIBC ex: gmake -f netware\nlm_libc_bsdsock.mak
225
226
227You can also run the build scripts manually if you do not want to use the
228build.bat file. Run the following scripts in the "\openssl"
229subdirectory (in the order listed below):
230
231 perl configure no-asm [other config opts] [netware-clib|netware-libc|netware-libc-bsdsock]
232 configures no assembly build for specified netware environment
233 (CLIB or LIBC).
234
235 perl util\mkfiles.pl >MINFO
236 generates a listing of source files (used by mk1mf)
237
238 perl util\mk1mf.pl no-asm [other config opts] [netware-clib|netware-libc|netware-libc-bsdsock >netware\nlm.mak
239 generates the makefile for NetWare
240
241 gmake -f netware\nlm.mak
242 build with the make tool (nmake.exe also works)
243
244NOTE: If you are building using the assembly option, you must also run the
245various Perl scripts to generate the assembly files. See build.bat
246for an example of running the various assembly scripts. You must use the
247"no-asm" option to build without assembly. The configure and mk1mf scripts
248also have various other options. See the scripts for more information.
249
250
251The output from the build is placed in the following directories:
252
253 CLIB Debug build:
254 out_nw_clib.dbg - static libs & test nlm(s)
255 tmp_nw_clib.dbg - temporary build files
256 outinc_nw_clib - necessary include files
257
258 CLIB Non-debug build:
259 out_nw_clib - static libs & test nlm(s)
260 tmp_nw_clib - temporary build files
261 outinc_nw_clib - necesary include files
262
263 LIBC Debug build:
264 out_nw_libc.dbg - static libs & test nlm(s)
265 tmp_nw_libc.dbg - temporary build files
266 outinc_nw_libc - necessary include files
267
268 LIBC Non-debug build:
269 out_nw_libc - static libs & test nlm(s)
270 tmp_nw_libc - temporary build files
271 outinc_nw_libc - necesary include files
272
273
274TESTING:
275--------
276The build process creates the OpenSSL static libs ( crypto.lib, ssl.lib,
277rsaglue.lib ) and several test programs. You should copy the test programs
278to your NetWare server and run the tests.
279
280The batch file "netware\cpy_tests.bat" will copy all the necessary files
281to your server for testing. In order to run the batch file, you need a
282drive mapped to your target server. It will create an "OpenSSL" directory
283on the drive and copy the test files to it. CAUTION: If a directory with the
284name of "OpenSSL" already exists, it will be deleted.
285
286To run cpy_tests.bat:
287
288 netware\cpy_tests [output directory] [NetWare drive]
289
290 output directory - "out_nw_clib.dbg", "out_nw_libc", etc.
291 NetWare drive - drive letter of mapped drive
292
293 CLIB ex: netware\cpy_tests out_nw_clib m:
294 LIBC ex: netware\cpy_tests out_nw_libc m:
295
296
297The Perl script, "do_tests.pl", in the "OpenSSL" directory on the server
298should be used to execute the tests. Before running the script, make sure
299your SEARCH PATH includes the "OpenSSL" directory. For example, if you
300copied the files to the "sys:" volume you use the command:
301
302 SEARCH ADD SYS:\OPENSSL
303
304
305To run do_tests.pl type (at the console prompt):
306
307 perl \openssl\do_tests.pl [options]
308
309 options:
310 -p - pause after executing each test
311
312The do_tests.pl script generates a log file "\openssl\test_out\tests.log"
313which should be reviewed for errors. Any errors will be denoted by the word
314"ERROR" in the log.
315
316DEVELOPING WITH THE OPENSSL SDK:
317--------------------------------
318Now that everything is built and tested, you are ready to use the OpenSSL
319libraries in your development.
320
321There is no real installation procedure, just copy the static libs and
322headers to your build location. The libs (crypto.lib & ssl.lib) are
323located in the appropriate "out_nw_XXXX" directory
324(out_nw_clib, out_nw_libc, etc).
325
326The headers are located in the appropriate "outinc_nw_XXX" directory
327(outinc_nw_clib, outinc_nw_libc).
328
329One suggestion is to create the following directory
330structure for the OpenSSL SDK:
331
332 \openssl
333 |- bin
334 | |- openssl.nlm
335 | |- (other tests you want)
336 |
337 |- lib
338 | | - crypto.lib
339 | | - ssl.lib
340 |
341 |- include
342 | | - openssl
343 | | | - (all the headers in "outinc_nw\openssl")
344
345
346The program "openssl.nlm" can be very useful. It has dozens of
347options and you may want to keep it handy for debugging, testing, etc.
348
349When building your apps using OpenSSL, define "NETWARE". It is needed by
350some of the OpenSSL headers. One way to do this is with a compile option,
351for example "-DNETWARE".
352
353
354
355NOTES:
356------
357
358Resource leaks in Tests
359------------------------
360Some OpenSSL tests do not clean up resources and NetWare reports
361the resource leaks when the tests unload. If this really bugs you,
362you can stop the messages by setting the developer option off at the console
363prompt (set developer option = off). Or better yet, fix the tests to
364clean up the resources!
365
366
367Multi-threaded Development
368---------------------------
369The NetWare version of OpenSSL is thread-safe, however multi-threaded
370applications must provide the necessary locking function callbacks. This
371is described in doc\threads.doc. The file "openssl-x.x.x\crypto\threads\mttest.c"
372is a multi-threaded test program and demonstrates the locking functions.
373
374
375What is openssl2.nlm?
376---------------------
377The openssl program has numerous options and can be used for many different
378things. Many of the options operate in an interactive mode requiring the
379user to enter data. Because of this, a default screen is created for the
380program. However, when running the test script it is not desirable to
381have a seperate screen. Therefore, the build also creates openssl2.nlm.
382Openssl2.nlm is functionally identical but uses the console screen.
383Openssl2 can be used when a non-interactive mode is desired.
384
385NOTE: There are may other possibilities (command line options, etc)
386which could have been used to address the screen issue. The openssl2.nlm
387option was chosen because it impacted only the build not the code.
388
389
390Why only static libraries?
391--------------------------
392Globals, globals, and more globals. The OpenSSL code uses many global
393variables that are allocated and initialized when used for the first time.
394
395On NetWare, most applications (at least historically) run in the kernel.
396When running in the kernel, there is one instance of global variables.
397For regular application type NLM(s) this isn't a problem because they are
398the only ones using the globals. However, for a library NLM (an NLM which
399exposes functions and has no threads of execution), the globals cause
400problems. Applications could inadvertently step on each other if they
401change some globals. Even worse, the first application that triggers a
402global to be allocated and initialized has the allocated memory charged to
403itself. Now when that application unloads, NetWare will clean up all the
404applicaton's memory. The global pointer variables inside OpenSSL now
405point to freed memory. An abend waiting to happen!
406
407To work correctly in the kernel, library NLM(s) that use globals need to
408provide a set of globals (instance data) for each application. Another
409option is to require the library only be loaded in a protected address
410space along with the application using it.
411
412Modifying the OpenSSL code to provide a set of globals (instance data) for
413each application isn't technically difficult, but due to the large number
414globals it would require substantial code changes and it wasn't done. Hence,
415the build currently only builds static libraries which are then linked
416into each application.
417
418NOTE: If you are building a library NLM that uses the OpenSSL static
419libraries, you will still have to deal with the global variable issue.
420This is because when you link in the OpenSSL code you bring in all the
421globals. One possible solution for the global pointer variables is to
422register memory functions with OpenSSL which allocate memory and charge it
423to your library NLM (see the function CRYPTO_set_mem_functions). However,
424be aware that now all memory allocated by OpenSSL is charged to your NLM.
425
426
427CodeWarrior Tools and W2K
428---------------------------
429There have been problems reported with the CodeWarrior Linker
430(mwldnlm.exe) in the PDK 2.1 for NetWare when running on Windows 2000. The
431problems cause the link step to fail. The only work around is to obtain an
432updated linker from Metrowerks. It is expected Metrowerks will release
433PDK 3.0 (in beta testing at this time - May, 2001) in the near future which
434will fix these problems.
435
436
437Makefile "vclean"
438------------------
439The generated makefile has a "vclean" target which cleans up the build
440directories. If you have been building successfully and suddenly
441experience problems, use "vclean" (gmake -f netware\nlm_xxxx.mak vclean) and retry.
442
443
444"Undefined Symbol" Linker errors
445--------------------------------
446There have been linker errors reported when doing a CLIB build. The problems
447occur because some versions of the CLIB SDK import files inadvertently
448left out some symbols. One symbol in particular is "_lrotl". The missing
449functions are actually delivered in the binaries, but they were left out of
450the import files. The issues should be fixed in the September 2001 release
451of the NDK. If you experience the problems you can temporarily
452work around it by manually adding the missing symbols to your version of
453"clib.imp".
454
diff --git a/src/lib/libssl/src/INSTALL.OS2 b/src/lib/libssl/src/INSTALL.OS2
deleted file mode 100644
index 530316db18..0000000000
--- a/src/lib/libssl/src/INSTALL.OS2
+++ /dev/null
@@ -1,31 +0,0 @@
1
2 Installation on OS/2
3 --------------------
4
5 You need to have the following tools installed:
6
7 * EMX GCC
8 * PERL
9 * GNU make
10
11
12 To build the makefile, run
13
14 > os2\os2-emx
15
16 This will configure OpenSSL and create OS2-EMX.mak which you then use to
17 build the OpenSSL libraries & programs by running
18
19 > make -f os2-emx.mak
20
21 If that finishes successfully you will find the libraries and programs in the
22 "out" directory.
23
24 Alternatively, you can make a dynamic build that puts the library code into
25 crypto.dll and ssl.dll by running
26
27 > make -f os2-emx-dll.mak
28
29 This will build the above mentioned dlls and a matching pair of import
30 libraries in the "out_dll" directory along with the set of test programs
31 and the openssl application.
diff --git a/src/lib/libssl/src/INSTALL.VMS b/src/lib/libssl/src/INSTALL.VMS
deleted file mode 100644
index e5d43a57ab..0000000000
--- a/src/lib/libssl/src/INSTALL.VMS
+++ /dev/null
@@ -1,293 +0,0 @@
1 VMS Installation instructions
2 written by Richard Levitte
3 <richard@levitte.org>
4
5
6Intro:
7======
8
9This file is divided in the following parts:
10
11 Requirements - Mandatory reading.
12 Checking the distribution - Mandatory reading.
13 Compilation - Mandatory reading.
14 Logical names - Mandatory reading.
15 Test - Mandatory reading.
16 Installation - Mandatory reading.
17 Backward portability - Read if it's an issue.
18 Possible bugs or quirks - A few warnings on things that
19 may go wrong or may surprise you.
20 TODO - Things that are to come.
21
22
23Requirements:
24=============
25
26To build and install OpenSSL, you will need:
27
28 * DEC C or some other ANSI C compiler. VAX C is *not* supported.
29 [Note: OpenSSL has only been tested with DEC C. Compiling with
30 a different ANSI C compiler may require some work]
31
32Checking the distribution:
33==========================
34
35There have been reports of places where the distribution didn't quite get
36through, for example if you've copied the tree from a NFS-mounted Unix
37mount point.
38
39The easiest way to check if everything got through as it should is to check
40for one of the following files:
41
42 [.CRYPTO]OPENSSLCONF.H_IN
43 [.CRYPTO]OPENSSLCONF_H.IN
44
45They should never exist both at once, but one of them should (preferably
46the first variant). If you can't find any of those two, something went
47wrong.
48
49The best way to get a correct distribution is to download the gzipped tar
50file from ftp://ftp.openssl.org/source/, use GUNZIP to uncompress it and
51use VMSTAR to unpack the resulting tar file.
52
53GUNZIP is available in many places on the net. One of the distribution
54points is the WKU software archive, ftp://ftp.wku.edu/vms/fileserv/ .
55
56VMSTAR is also available in many places on the net. The recommended place
57to find information about it is http://www.free.lp.se/vmstar/ .
58
59
60Compilation:
61============
62
63I've used the very good command procedures written by Robert Byer
64<byer@mail.all-net.net>, and just slightly modified them, making
65them slightly more general and easier to maintain.
66
67You can actually compile in almost any directory separately. Look
68for a command procedure name xxx-LIB.COM (in the library directories)
69or MAKExxx.COM (in the program directories) and read the comments at
70the top to understand how to use them. However, if you want to
71compile all you can get, the simplest is to use MAKEVMS.COM in the top
72directory. The syntax is the following:
73
74 @MAKEVMS <option> <bits> <debug-p> [<compiler>]
75
76<option> must be one of the following:
77
78 ALL Just build "everything".
79 CONFIG Just build the "[.CRYPTO]OPENSSLCONF.H" file.
80 BUILDINF Just build the "[.INCLUDE]BUILDINF.H" file.
81 SOFTLINKS Just copies some files, to simulate Unix soft links.
82 BUILDALL Same as ALL, except CONFIG, BUILDINF and SOFTLINKS aren't done.
83 RSAREF Just build the "[.xxx.EXE.RSAREF]LIBRSAGLUE.OLB" library.
84 CRYPTO Just build the "[.xxx.EXE.CRYPTO]LIBCRYPTO.OLB" library.
85 SSL Just build the "[.xxx.EXE.SSL]LIBSSL.OLB" library.
86 SSL_TASK Just build the "[.xxx.EXE.SSL]SSL_TASK.EXE" program.
87 TEST Just build the "[.xxx.EXE.TEST]" test programs for OpenSSL.
88 APPS Just build the "[.xxx.EXE.APPS]" application programs for OpenSSL.
89
90<bits> must be one of the following:
91
92 "" compile using default pointer size
93 32 compile using 32 bit pointer size
94 64 compile using 64 bit pointer size
95
96<debug-p> must be one of the following:
97
98 DEBUG compile with debugging info (will not optimize)
99 NODEBUG compile without debugging info (will optimize)
100
101<compiler> must be one of the following:
102
103 DECC For DEC C.
104 GNUC For GNU C.
105
106
107You will find the crypto library in [.xxx.EXE.CRYPTO] (where xxx is VAX,
108ALPHA or IA64), called SSL_LIBCRYPTO32.OLB or SSL_LIBCRYPTO.OLB depending
109on how it was built. You will find the SSL library in [.xxx.EXE.SSL],
110named SSL_LIBSSL32.OLB or SSL_LIBSSL.OLB, and you will find a bunch of
111useful programs in [.xxx.EXE.APPS]. However, these shouldn't be used
112right off unless it's just to test them. For production use, make sure
113you install first, see Installation below.
114
115Note 1: Some programs in this package require a TCP/IP library.
116
117Note 2: if you want to compile the crypto library only, please make sure
118 you have at least done a @MAKEVMS CONFIG, a @MAKEVMS BUILDINF and
119 a @MAKEVMS SOFTLINKS. A lot of things will break if you don't.
120
121
122Logical names:
123==============
124
125There are a few things that can't currently be given through the command
126line. Instead, logical names are used.
127
128Currently, the logical names supported are:
129
130 OPENSSL_NO_ASM with value YES, the assembler parts of OpenSSL will
131 not be used. Instead, plain C implementations are
132 used. This is good to try if something doesn't work.
133 OPENSSL_NO_'alg' with value YES, the corresponding crypto algorithm
134 will not be implemented. Supported algorithms to
135 do this with are: RSA, DSA, DH, MD2, MD4, MD5, RIPEMD,
136 SHA, DES, MDC2, CR2, RC4, RC5, IDEA, BF, CAST, HMAC,
137 SSL2. So, for example, having the logical name
138 OPENSSL_NO_RSA with the value YES means that the
139 LIBCRYPTO.OLB library will not contain an RSA
140 implementation.
141
142
143Test:
144=====
145
146Testing is very simple, just do the following:
147
148 @[.TEST]TESTS
149
150If a test fails, try with defining the logical name OPENSSL_NO_ASM (yes,
151it's an ugly hack!) and rebuild. Please send a bug report to
152<openssl-bugs@openssl.org>, including the output of "openssl version -a"
153and of the failed test.
154
155
156Installation:
157=============
158
159Installation is easy, just do the following:
160
161 @INSTALL <root> <bits>
162
163<root> is the directory in which everything will be installed,
164subdirectories, libraries, header files, programs and startup command
165procedures.
166
167<bits> works the same way as for MAKEVMS.COM
168
169N.B.: INSTALL.COM builds a new directory structure, different from
170the directory tree where you have now build OpenSSL.
171
172In the [.VMS] subdirectory of the installation, you will find the
173following command procedures:
174
175 OPENSSL_STARTUP.COM
176
177 defines all needed logical names. Takes one argument that
178 tells it in what logical name table to insert the logical
179 names. If you insert if it SYS$MANAGER:SYSTARTUP_VMS.COM, the
180 call should look like this:
181
182 @openssldev:[openssldir.VMS]OPENSSL_STARTUP "/SYSTEM"
183
184 OPENSSL_UTILS.COM
185
186 sets up the symbols to the applications. Should be called
187 from for example SYS$MANAGER:SYLOGIN.COM
188
189 OPENSSL_UNDO.COM
190
191 deassigns the logical names created with OPENSSL_STARTUP.COM.
192
193The logical names that are set up are the following:
194
195 SSLROOT a dotted concealed logical name pointing at the
196 root directory.
197
198 SSLCERTS Initially an empty directory, this is the default
199 location for certificate files.
200 SSLPRIVATE Initially an empty directory, this is the default
201 location for private key files.
202
203 SSLEXE Contains the openssl binary and a few other utility
204 programs.
205 SSLINCLUDE Contains the header files needed if you want to
206 compile programs with libcrypto or libssl.
207 SSLLIB Contains the OpenSSL library files themselves:
208 - SSL_LIBCRYPTO32.OLB and SSL_LIBSSL32.OLB or
209 - SSL_LIBCRYPTO.OLB and SSL_LIBSSL.OLB
210
211 OPENSSL Same as SSLINCLUDE. This is because the standard
212 way to include OpenSSL header files from version
213 0.9.3 and on is:
214
215 #include <openssl/header.h>
216
217 For more info on this issue, see the INSTALL. file
218 (the NOTE in section 4 of "Installation in Detail").
219 You don't need to "deleting old header files"!!!
220
221
222Backward portability:
223=====================
224
225One great problem when you build a library is making sure it will work
226on as many versions of VMS as possible. Especially, code compiled on
227OpenVMS version 7.x and above tend to be unusable in version 6.x or
228lower, because some C library routines have changed names internally
229(the C programmer won't usually see it, because the old name is
230maintained through C macros). One obvious solution is to make sure
231you have a development machine with an old enough version of OpenVMS.
232However, if you are stuck with a bunch of Alphas running OpenVMS version
2337.1, you seem to be out of luck. Fortunately, the DEC C header files
234are cluttered with conditionals that make some declarations and definitions
235dependent on the OpenVMS version or the C library version, *and* you
236can use those macros to simulate older OpenVMS or C library versions,
237by defining the macros _VMS_V6_SOURCE, __VMS_VER and __CTRL_VER with
238correct values. In the compilation scripts, I've provided the possibility
239for the user to influence the creation of such macros, through a bunch of
240symbols, all having names starting with USER_. Here's the list of them:
241
242 USER_CCFLAGS - Used to give additional qualifiers to the
243 compiler. It can't be used to define macros
244 since the scripts will do such things as well.
245 To do such things, use USER_CCDEFS.
246 USER_CCDEFS - Used to define macros on the command line. The
247 value of this symbol will be inserted inside a
248 /DEFINE=(...).
249 USER_CCDISABLEWARNINGS - Used to disable some warnings. The value is
250 inserted inside a /DISABLE=WARNING=(...).
251
252So, to maintain backward compatibility with older VMS versions, do the
253following before you start compiling:
254
255 $ USER_CCDEFS := _VMS_V6_SOURCE=1,__VMS_VER=60000000,__CRTL_VER=60000000
256 $ USER_CCDISABLEWARNINGS := PREOPTW
257
258The USER_CCDISABLEWARNINGS is there because otherwise, DEC C will complain
259that those macros have been changed.
260
261Note: Currently, this is only useful for library compilation. The
262 programs will still be linked with the current version of the
263 C library shareable image, and will thus complain if they are
264 faced with an older version of the same C library shareable image.
265 This will probably be fixed in a future revision of OpenSSL.
266
267
268Possible bugs or quirks:
269========================
270
271I'm not perfectly sure all the programs will use the SSLCERTS:
272directory by default, it may very well be that you have to give them
273extra arguments. Please experiment.
274
275
276TODO:
277=====
278
279There are a few things that need to be worked out in the VMS version of
280OpenSSL, still:
281
282- Description files. ("Makefile's" :-))
283- Script code to link an already compiled build tree.
284- A VMSINSTALlable version (way in the future, unless someone else hacks).
285- shareable images (DLL for you Windows folks).
286
287There may be other things that I have missed and that may be desirable.
288Please send mail to <openssl-users@openssl.org> or to me directly if you
289have any ideas.
290
291--
292Richard Levitte <richard@levitte.org>
2932000-02-27, 2011-03-18
diff --git a/src/lib/libssl/src/INSTALL.W32 b/src/lib/libssl/src/INSTALL.W32
deleted file mode 100644
index 80e538273e..0000000000
--- a/src/lib/libssl/src/INSTALL.W32
+++ /dev/null
@@ -1,325 +0,0 @@
1
2 INSTALLATION ON THE WIN32 PLATFORM
3 ----------------------------------
4
5 [Instructions for building for Windows CE can be found in INSTALL.WCE]
6 [Instructions for building for Win64 can be found in INSTALL.W64]
7
8 Here are a few comments about building OpenSSL for Win32 environments,
9 such as Windows NT and Windows 9x. It should be noted though that
10 Windows 9x are not ordinarily tested. Its mention merely means that we
11 attempt to maintain certain programming discipline and pay attention
12 to backward compatibility issues, in other words it's kind of expected
13 to work on Windows 9x, but no regression tests are actually performed.
14
15 On additional note newer OpenSSL versions are compiled and linked with
16 Winsock 2. This means that minimum OS requirement was elevated to NT 4
17 and Windows 98 [there is Winsock 2 update for Windows 95 though].
18
19 - you need Perl for Win32. Unless you will build on Cygwin, you will need
20 ActiveState Perl, available from http://www.activestate.com/ActivePerl.
21
22 - one of the following C compilers:
23
24 * Visual C++
25 * Borland C
26 * GNU C (Cygwin or MinGW)
27
28- Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/
29 is required if you intend to utilize assembler modules. Note that NASM
30 is now the only supported assembler.
31
32 If you are compiling from a tarball or a Git snapshot then the Win32 files
33 may well be not up to date. This may mean that some "tweaking" is required to
34 get it all to work. See the trouble shooting section later on for if (when?)
35 it goes wrong.
36
37 Visual C++
38 ----------
39
40 If you want to compile in the assembly language routines with Visual
41 C++, then you will need already mentioned Netwide Assembler binary,
42 nasmw.exe or nasm.exe, to be available on your %PATH%.
43
44 Firstly you should run Configure with platform VC-WIN32:
45
46 > perl Configure VC-WIN32 --prefix=c:\some\openssl\dir
47
48 Where the prefix argument specifies where OpenSSL will be installed to.
49
50 Next you need to build the Makefiles and optionally the assembly
51 language files:
52
53 - If you are using NASM then run:
54
55 > ms\do_nasm
56
57 - If you don't want to use the assembly language files at all then run:
58
59 > perl Configure VC-WIN32 no-asm --prefix=c:/some/openssl/dir
60 > ms\do_ms
61
62 If you get errors about things not having numbers assigned then check the
63 troubleshooting section: you probably won't be able to compile it as it
64 stands.
65
66 Then from the VC++ environment at a prompt do:
67
68 > nmake -f ms\ntdll.mak
69
70 If all is well it should compile and you will have some DLLs and
71 executables in out32dll. If you want to try the tests then do:
72
73 > nmake -f ms\ntdll.mak test
74
75
76 To install OpenSSL to the specified location do:
77
78 > nmake -f ms\ntdll.mak install
79
80 Tweaks:
81
82 There are various changes you can make to the Win32 compile
83 environment. By default the library is not compiled with debugging
84 symbols. If you use the platform debug-VC-WIN32 instead of VC-WIN32
85 then debugging symbols will be compiled in.
86
87 By default in 1.0.0 OpenSSL will compile builtin ENGINES into the
88 separate shared librariesy. If you specify the "enable-static-engine"
89 option on the command line to Configure the shared library build
90 (ms\ntdll.mak) will compile the engines into libeay32.dll instead.
91
92 The default Win32 environment is to leave out any Windows NT specific
93 features.
94
95 If you want to enable the NT specific features of OpenSSL (currently
96 only the logging BIO) follow the instructions above but call the batch
97 file do_nt.bat instead of do_ms.bat.
98
99 You can also build a static version of the library using the Makefile
100 ms\nt.mak
101
102
103 Borland C++ builder 5
104 ---------------------
105
106 * Configure for building with Borland Builder:
107 > perl Configure BC-32
108
109 * Create the appropriate makefile
110 > ms\do_nasm
111
112 * Build
113 > make -f ms\bcb.mak
114
115 Borland C++ builder 3 and 4
116 ---------------------------
117
118 * Setup PATH. First must be GNU make then bcb4/bin
119
120 * Run ms\bcb4.bat
121
122 * Run make:
123 > make -f bcb.mak
124
125 GNU C (Cygwin)
126 --------------
127
128 Cygwin implements a Posix/Unix runtime system (cygwin1.dll) on top of
129 Win32 subsystem and provides a bash shell and GNU tools environment.
130 Consequently, a make of OpenSSL with Cygwin is virtually identical to
131 Unix procedure. It is also possible to create Win32 binaries that only
132 use the Microsoft C runtime system (msvcrt.dll or crtdll.dll) using
133 MinGW. MinGW can be used in the Cygwin development environment or in a
134 standalone setup as described in the following section.
135
136 To build OpenSSL using Cygwin:
137
138 * Install Cygwin (see http://cygwin.com/)
139
140 * Install Perl and ensure it is in the path. Both Cygwin perl
141 (5.6.1-2 or newer) and ActivePerl work.
142
143 * Run the Cygwin bash shell
144
145 * $ tar zxvf openssl-x.x.x.tar.gz
146 $ cd openssl-x.x.x
147
148 To build the Cygwin version of OpenSSL:
149
150 $ ./config
151 [...]
152 $ make
153 [...]
154 $ make test
155 $ make install
156
157 This will create a default install in /usr/local/ssl.
158
159 To build the MinGW version (native Windows) in Cygwin:
160
161 $ ./Configure mingw
162 [...]
163 $ make
164 [...]
165 $ make test
166 $ make install
167
168 Cygwin Notes:
169
170 "make test" and normal file operations may fail in directories
171 mounted as text (i.e. mount -t c:\somewhere /home) due to Cygwin
172 stripping of carriage returns. To avoid this ensure that a binary
173 mount is used, e.g. mount -b c:\somewhere /home.
174
175 "bc" is not provided in older Cygwin distribution. This causes a
176 non-fatal error in "make test" but is otherwise harmless. If
177 desired and needed, GNU bc can be built with Cygwin without change.
178
179 GNU C (MinGW/MSYS)
180 -------------
181
182 * Compiler and shell environment installation:
183
184 MinGW and MSYS are available from http://www.mingw.org/, both are
185 required. Run the installers and do whatever magic they say it takes
186 to start MSYS bash shell with GNU tools on its PATH.
187
188 N.B. Since source tar-ball can contain symbolic links, it's essential
189 that you use accompanying MSYS tar to unpack the source. It will
190 either handle them in one way or another or fail to extract them,
191 which does the trick too. Latter means that you may safely ignore all
192 "cannot create symlink" messages, as they will be "re-created" at
193 configure stage by copying corresponding files. Alternative programs
194 were observed to create empty files instead, which results in build
195 failure.
196
197 * Compile OpenSSL:
198
199 $ ./config
200 [...]
201 $ make
202 [...]
203 $ make test
204
205 This will create the library and binaries in root source directory
206 and openssl.exe application in apps directory.
207
208 It is also possible to cross-compile it on Linux by configuring
209 with './Configure --cross-compile-prefix=i386-mingw32- mingw ...'.
210 'make test' is naturally not applicable then.
211
212 libcrypto.a and libssl.a are the static libraries. To use the DLLs,
213 link with libeay32.a and libssl32.a instead.
214
215 See troubleshooting if you get error messages about functions not
216 having a number assigned.
217
218 Installation
219 ------------
220
221 If you used the Cygwin procedure above, you have already installed and
222 can skip this section. For all other procedures, there's currently no real
223 installation procedure for Win32. There are, however, some suggestions:
224
225 - do nothing. The include files are found in the inc32/ subdirectory,
226 all binaries are found in out32dll/ or out32/ depending if you built
227 dynamic or static libraries.
228
229 - do as is written in INSTALL.Win32 that comes with modssl:
230
231 $ md c:\openssl
232 $ md c:\openssl\bin
233 $ md c:\openssl\lib
234 $ md c:\openssl\include
235 $ md c:\openssl\include\openssl
236 $ copy /b inc32\openssl\* c:\openssl\include\openssl
237 $ copy /b out32dll\ssleay32.lib c:\openssl\lib
238 $ copy /b out32dll\libeay32.lib c:\openssl\lib
239 $ copy /b out32dll\ssleay32.dll c:\openssl\bin
240 $ copy /b out32dll\libeay32.dll c:\openssl\bin
241 $ copy /b out32dll\openssl.exe c:\openssl\bin
242
243 Of course, you can choose another device than c:. C: is used here
244 because that's usually the first (and often only) harddisk device.
245 Note: in the modssl INSTALL.Win32, p: is used rather than c:.
246
247
248 Troubleshooting
249 ---------------
250
251 Since the Win32 build is only occasionally tested it may not always compile
252 cleanly. If you get an error about functions not having numbers assigned
253 when you run ms\do_ms then this means the Win32 ordinal files are not up to
254 date. You can do:
255
256 > perl util\mkdef.pl crypto ssl update
257
258 then ms\do_XXX should not give a warning any more. However the numbers that
259 get assigned by this technique may not match those that eventually get
260 assigned in the Git tree: so anything linked against this version of the
261 library may need to be recompiled.
262
263 If you get errors about unresolved symbols there are several possible
264 causes.
265
266 If this happens when the DLL is being linked and you have disabled some
267 ciphers then it is possible the DEF file generator hasn't removed all
268 the disabled symbols: the easiest solution is to edit the DEF files manually
269 to delete them. The DEF files are ms\libeay32.def ms\ssleay32.def.
270
271 Another cause is if you missed or ignored the errors about missing numbers
272 mentioned above.
273
274 If you get warnings in the code then the compilation will halt.
275
276 The default Makefile for Win32 halts whenever any warnings occur. Since VC++
277 has its own ideas about warnings which don't always match up to other
278 environments this can happen. The best fix is to edit the file with the
279 warning in and fix it. Alternatively you can turn off the halt on warnings by
280 editing the CFLAG line in the Makefile and deleting the /WX option.
281
282 You might get compilation errors. Again you will have to fix these or report
283 them.
284
285 One final comment about compiling applications linked to the OpenSSL library.
286 If you don't use the multithreaded DLL runtime library (/MD option) your
287 program will almost certainly crash because malloc gets confused -- the
288 OpenSSL DLLs are statically linked to one version, the application must
289 not use a different one. You might be able to work around such problems
290 by adding CRYPTO_malloc_init() to your program before any calls to the
291 OpenSSL libraries: This tells the OpenSSL libraries to use the same
292 malloc(), free() and realloc() as the application. However there are many
293 standard library functions used by OpenSSL that call malloc() internally
294 (e.g. fopen()), and OpenSSL cannot change these; so in general you cannot
295 rely on CRYPTO_malloc_init() solving your problem, and you should
296 consistently use the multithreaded library.
297
298 Linking your application
299 ------------------------
300
301 If you link with static OpenSSL libraries [those built with ms/nt.mak],
302 then you're expected to additionally link your application with
303 WS2_32.LIB, ADVAPI32.LIB, GDI32.LIB and USER32.LIB. Those developing
304 non-interactive service applications might feel concerned about linking
305 with the latter two, as they are justly associated with interactive
306 desktop, which is not available to service processes. The toolkit is
307 designed to detect in which context it's currently executed, GUI,
308 console app or service, and act accordingly, namely whether or not to
309 actually make GUI calls. Additionally those who wish to
310 /DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL and actually keep them
311 off service process should consider implementing and exporting from
312 .exe image in question own _OPENSSL_isservice not relying on USER32.DLL.
313 E.g., on Windows Vista and later you could:
314
315 __declspec(dllexport) __cdecl BOOL _OPENSSL_isservice(void)
316 { DWORD sess;
317 if (ProcessIdToSessionId(GetCurrentProcessId(),&sess))
318 return sess==0;
319 return FALSE;
320 }
321
322 If you link with OpenSSL .DLLs, then you're expected to include into
323 your application code small "shim" snippet, which provides glue between
324 OpenSSL BIO layer and your compiler run-time. Look up OPENSSL_Applink
325 reference page for further details.
diff --git a/src/lib/libssl/src/INSTALL.W64 b/src/lib/libssl/src/INSTALL.W64
deleted file mode 100644
index 9fa7a19205..0000000000
--- a/src/lib/libssl/src/INSTALL.W64
+++ /dev/null
@@ -1,66 +0,0 @@
1
2 INSTALLATION ON THE WIN64 PLATFORM
3 ----------------------------------
4
5 Caveat lector
6 -------------
7
8 As of moment of this writing Win64 support is classified "initial"
9 for the following reasons.
10
11 - No assembler modules are engaged upon initial 0.9.8 release.
12 - API might change within 0.9.8 life-span, *but* in a manner which
13 doesn't break backward binary compatibility. Or in other words,
14 application programs compiled with initial 0.9.8 headers will
15 be expected to work with future minor release .DLL without need
16 to re-compile, even if future minor release features modified API.
17 - Above mentioned API modifications have everything to do with
18 elimination of a number of limitations, which are normally
19 considered inherent to 32-bit platforms. Which in turn is why they
20 are treated as limitations on 64-bit platform such as Win64:-)
21 The current list comprises [but not necessarily limited to]:
22
23 - null-terminated strings may not be longer than 2G-1 bytes,
24 longer strings are treated as zero-length;
25 - dynamically and *internally* allocated chunks can't be larger
26 than 2G-1 bytes;
27 - inability to encrypt/decrypt chunks of data larger than 4GB
28 [it's possibly to *hash* chunks of arbitrary size through];
29
30 Neither of these is actually big deal and hardly encountered
31 in real-life applications.
32
33 Compiling procedure
34 -------------------
35
36 You will need Perl. You can run under Cygwin or you can download
37 ActiveState Perl from http://www.activestate.com/ActivePerl.
38
39 You will need Microsoft Platform SDK, available for download at
40 http://www.microsoft.com/msdownload/platformsdk/sdkupdate/. As per
41 April 2005 Platform SDK is equipped with Win64 compilers, as well
42 as assemblers, but it might change in the future.
43
44 To build for Win64/x64:
45
46 > perl Configure VC-WIN64A
47 > ms\do_win64a
48 > nmake -f ms\ntdll.mak
49 > cd out32dll
50 > ..\ms\test
51
52 To build for Win64/IA64:
53
54 > perl Configure VC-WIN64I
55 > ms\do_win64i
56 > nmake -f ms\ntdll.mak
57 > cd out32dll
58 > ..\ms\test
59
60 Naturally test-suite itself has to be executed on the target platform.
61
62 Installation
63 ------------
64
65 TBD, for now see INSTALL.W32.
66
diff --git a/src/lib/libssl/src/INSTALL.WCE b/src/lib/libssl/src/INSTALL.WCE
deleted file mode 100644
index d78c61afa8..0000000000
--- a/src/lib/libssl/src/INSTALL.WCE
+++ /dev/null
@@ -1,95 +0,0 @@
1
2 INSTALLATION FOR THE WINDOWS CE PLATFORM
3 ----------------------------------------
4
5 Building OpenSSL for Windows CE requires the following external tools:
6
7 * Microsoft eMbedded Visual C++ 3.0 or later
8 * Appropriate SDK might be required
9 * Perl for Win32 [commonly recommended ActiveState Perl is available
10 from http://www.activestate.com/Products/ActivePerl/]
11
12 * wcecompat compatibility library available at
13 http://www.essemer.com.au/windowsce/
14 * Optionally ceutils for running automated tests (same location)
15
16 _or_
17
18 * PocketConsole driver and PortSDK available at
19 http://www.symbolictools.de/public/pocketconsole/
20 * CMD command interpreter (same location)
21
22 As Windows CE support in OpenSSL relies on 3rd party compatibility
23 library, it's appropriate to check corresponding URL for updates. For
24 example if you choose wcecompat, note that as for the moment of this
25 writing version 1.2 is available and actually required for WCE 4.2
26 and newer platforms. All wcecompat issues should be directed to
27 www.essemer.com.au.
28
29 Why compatibility library at all? The C Runtime Library implementation
30 for Windows CE that is included with Microsoft eMbedded Visual C++ is
31 incomplete and in some places incorrect. Compatibility library plugs
32 the holes and tries to bring the Windows CE CRT to [more] usable level.
33 Most gaping hole in CRT is support for stdin/stdout/stderr IO, which
34 proposed compatibility libraries solve in two different ways: wcecompat
35 redirects IO to active sync link, while PortSDK - to NT-like console
36 driver on the handheld itself.
37
38 Building
39 --------
40
41 Setup the eMbedded Visual C++ environment. There are batch files for doing
42 this installed with eVC++. For an ARM processor, for example, execute:
43
44 > "C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN\WCEARM.BAT"
45
46 Next pick compatibility library according to your preferences.
47
48 1. To choose wcecompat set up WCECOMPAT environment variable pointing
49 at the location of wcecompat tree "root":
50
51 > set WCECOMPAT=C:\wcecompat
52 > set PORTSDK_LIBPATH=
53
54 2. To choose PortSDK set up PORTSDK_LIBPATH to point at hardware-
55 specific location where your portlib.lib is installed:
56
57 > set PORTSDK_LIBPATH=C:\PortSDK\lib\ARM
58 > set WCECOMPAT=
59
60 Note that you may not set both variables.
61
62 Next you should run Configure:
63
64 > perl Configure VC-CE
65
66 Next you need to build the Makefiles:
67
68 > ms\do_ms
69
70 If you get errors about things not having numbers assigned then check the
71 troubleshooting section in INSTALL.W32: you probably won't be able to compile
72 it as it stands.
73
74 Then from the VC++ environment at a prompt do:
75
76 > nmake -f ms\cedll.mak
77
78 [note that static builds are not supported under CE]
79
80 If all is well it should compile and you will have some DLLs and executables
81 in out32dll*.
82
83 <<< everyting below needs revision in respect to wcecompat vs. PortSDK >>>
84
85 If you want
86 to try the tests then make sure the ceutils are in the path and do:
87
88 > cd out32
89 > ..\ms\testce
90
91 This will copy each of the test programs to the Windows CE device and execute
92 them, displaying the output of the tests on this computer. The output should
93 look similar to the output produced by running the tests for a regular Windows
94 build.
95
diff --git a/src/lib/libssl/src/PROBLEMS b/src/lib/libssl/src/PROBLEMS
deleted file mode 100644
index 3eaab01f2c..0000000000
--- a/src/lib/libssl/src/PROBLEMS
+++ /dev/null
@@ -1,213 +0,0 @@
1* System libcrypto.dylib and libssl.dylib are used by system ld on MacOS X.
2
3
4 NOTE: The problem described here only applies when OpenSSL isn't built
5 with shared library support (i.e. without the "shared" configuration
6 option). If you build with shared library support, you will have no
7 problems as long as you set up DYLD_LIBRARY_PATH properly at all times.
8
9
10This is really a misfeature in ld, which seems to look for .dylib libraries
11along the whole library path before it bothers looking for .a libraries. This
12means that -L switches won't matter unless OpenSSL is built with shared
13library support.
14
15The workaround may be to change the following lines in apps/Makefile and
16test/Makefile:
17
18 LIBCRYPTO=-L.. -lcrypto
19 LIBSSL=-L.. -lssl
20
21to:
22
23 LIBCRYPTO=../libcrypto.a
24 LIBSSL=../libssl.a
25
26It's possible that something similar is needed for shared library support
27as well. That hasn't been well tested yet.
28
29
30Another solution that many seem to recommend is to move the libraries
31/usr/lib/libcrypto.0.9.dylib, /usr/lib/libssl.0.9.dylib to a different
32directory, build and install OpenSSL and anything that depends on your
33build, then move libcrypto.0.9.dylib and libssl.0.9.dylib back to their
34original places. Note that the version numbers on those two libraries
35may differ on your machine.
36
37
38As long as Apple doesn't fix the problem with ld, this problem building
39OpenSSL will remain as is. Well, the problem was addressed in 0.9.8f by
40passing -Wl,-search_paths_first, but it's unknown if the flag was
41supported from the initial MacOS X release.
42
43
44* Parallell make leads to errors
45
46While running tests, running a parallell make is a bad idea. Many test
47scripts use the same name for output and input files, which means different
48will interfere with each other and lead to test failure.
49
50The solution is simple for now: don't run parallell make when testing.
51
52
53* Bugs in gcc triggered
54
55- According to a problem report, there are bugs in gcc 3.0 that are
56 triggered by some of the code in OpenSSL, more specifically in
57 PEM_get_EVP_CIPHER_INFO(). The triggering code is the following:
58
59 header+=11;
60 if (*header != '4') return(0); header++;
61 if (*header != ',') return(0); header++;
62
63 What happens is that gcc might optimize a little too agressively, and
64 you end up with an extra incrementation when *header != '4'.
65
66 We recommend that you upgrade gcc to as high a 3.x version as you can.
67
68- According to multiple problem reports, some of our message digest
69 implementations trigger bug[s] in code optimizer in gcc 3.3 for sparc64
70 and gcc 2.96 for ppc. Former fails to complete RIPEMD160 test, while
71 latter - SHA one.
72
73 The recomendation is to upgrade your compiler. This naturally applies to
74 other similar cases.
75
76- There is a subtle Solaris x86-specific gcc run-time environment bug, which
77 "falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug
78 manifests itself as Segmentation Fault upon early application start-up.
79 The problem can be worked around by patching the environment according to
80 http://www.openssl.org/~appro/values.c.
81
82* solaris64-sparcv9-cc SHA-1 performance with WorkShop 6 compiler.
83
84As subject suggests SHA-1 might perform poorly (4 times slower)
85if compiled with WorkShop 6 compiler and -xarch=v9. The cause for
86this seems to be the fact that compiler emits multiplication to
87perform shift operations:-( To work the problem around configure
88with './Configure solaris64-sparcv9-cc -DMD32_REG_T=int'.
89
90* Problems with hp-parisc2-cc target when used with "no-asm" flag
91
92When using the hp-parisc2-cc target, wrong bignum code is generated.
93This is due to the SIXTY_FOUR_BIT build being compiled with the +O3
94aggressive optimization.
95The problem manifests itself by the BN_kronecker test hanging in an
96endless loop. Reason: the BN_kronecker test calls BN_generate_prime()
97which itself hangs. The reason could be tracked down to the bn_mul_comba8()
98function in bn_asm.c. At some occasions the higher 32bit value of r[7]
99is off by 1 (meaning: calculated=shouldbe+1). Further analysis failed,
100as no debugger support possible at +O3 and additional fprintf()'s
101introduced fixed the bug, therefore it is most likely a bug in the
102optimizer.
103The bug was found in the BN_kronecker test but may also lead to
104failures in other parts of the code.
105(See Ticket #426.)
106
107Workaround: modify the target to +O2 when building with no-asm.
108
109* Problems building shared libraries on SCO OpenServer Release 5.0.6
110 with gcc 2.95.3
111
112The symptoms appear when running the test suite, more specifically
113test/ectest, with the following result:
114
115OSSL_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
116ectest.c:186: ABORT
117
118The cause of the problem seems to be that isxdigit(), called from
119BN_hex2bn(), returns 0 on a perfectly legitimate hex digit. Further
120investigation shows that any of the isxxx() macros return 0 on any
121input. A direct look in the information array that the isxxx() use,
122called __ctype, shows that it contains all zeroes...
123
124Taking a look at the newly created libcrypto.so with nm, one can see
125that the variable __ctype is defined in libcrypto's .bss (which
126explains why it is filled with zeroes):
127
128$ nm -Pg libcrypto.so | grep __ctype
129__ctype B 0011659c
130__ctype2 U
131
132Curiously, __ctype2 is undefined, in spite of being declared in
133/usr/include/ctype.h in exactly the same way as __ctype.
134
135Any information helping to solve this issue would be deeply
136appreciated.
137
138NOTE: building non-shared doesn't come with this problem.
139
140* ULTRIX build fails with shell errors, such as "bad substitution"
141 and "test: argument expected"
142
143The problem is caused by ULTRIX /bin/sh supporting only original
144Bourne shell syntax/semantics, and the trouble is that the vast
145majority is so accustomed to more modern syntax, that very few
146people [if any] would recognize the ancient syntax even as valid.
147This inevitably results in non-trivial scripts breaking on ULTRIX,
148and OpenSSL isn't an exclusion. Fortunately there is workaround,
149hire /bin/ksh to do the job /bin/sh fails to do.
150
1511. Trick make(1) to use /bin/ksh by setting up following environ-
152 ment variables *prior* you execute ./Configure and make:
153
154 PROG_ENV=POSIX
155 MAKESHELL=/bin/ksh
156 export PROG_ENV MAKESHELL
157
158 or if your shell is csh-compatible:
159
160 setenv PROG_ENV POSIX
161 setenv MAKESHELL /bin/ksh
162
1632. Trick /bin/sh to use alternative expression evaluator. Create
164 following 'test' script for example in /tmp:
165
166 #!/bin/ksh
167 ${0##*/} "$@"
168
169 Then 'chmod a+x /tmp/test; ln /tmp/test /tmp/[' and *prepend*
170 your $PATH with chosen location, e.g. PATH=/tmp:$PATH. Alter-
171 natively just replace system /bin/test and /bin/[ with the
172 above script.
173
174* hpux64-ia64-cc fails blowfish test.
175
176Compiler bug, presumably at particular patch level. It should be noted
177that same compiler generates correct 32-bit code, a.k.a. hpux-ia64-cc
178target. Drop optimization level to +O2 when compiling 64-bit bf_skey.o.
179
180* no-engines generates errors.
181
182Unfortunately, the 'no-engines' configuration option currently doesn't
183work properly. Use 'no-hw' and you'll will at least get no hardware
184support. We'll see how we fix that on OpenSSL versions past 0.9.8.
185
186* 'make test' fails in BN_sqr [commonly with "error 139" denoting SIGSEGV]
187 if elder GNU binutils were deployed to link shared libcrypto.so.
188
189As subject suggests the failure is caused by a bug in elder binutils,
190either as or ld, and was observed on FreeBSD and Linux. There are two
191options. First is naturally to upgrade binutils, the second one - to
192reconfigure with additional no-sse2 [or 386] option passed to ./config.
193
194* If configured with ./config no-dso, toolkit still gets linked with -ldl,
195 which most notably poses a problem when linking with dietlibc.
196
197We don't have framework to associate -ldl with no-dso, therefore the only
198way is to edit Makefile right after ./config no-dso and remove -ldl from
199EX_LIBS line.
200
201* hpux-parisc2-cc no-asm build fails with SEGV in ECDSA/DH.
202
203Compiler bug, presumably at particular patch level. Remaining
204hpux*-parisc*-cc configurations can be affected too. Drop optimization
205level to +O2 when compiling bn_nist.o.
206
207* solaris64-sparcv9-cc link failure
208
209Solaris 8 ar can fail to maintain symbol table in .a, which results in
210link failures. Apply 109147-09 or later or modify Makefile generated
211by ./Configure solaris64-sparcv9-cc and replace RANLIB assignment with
212
213 RANLIB= /usr/ccs/bin/ar rs
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-11-26 14:46:19 +0000