Remove obsolete SSLeay instructions.

 you can still use "no-threads" to suppress an annoying warning message

 from the Configure script.)

--------------------------------------------------------------------------------

The orignal Unix build instructions from SSLeay follow. 

Note: some of this may be out of date and no longer applicable

--------------------------------------------------------------------------------

# When bringing the SSLeay distribution back from the evil intel world

# of Windows NT, do the following to make it nice again under unix :-)

# You don't normally need to run this.

sh util/fixNT.sh	# This only works for NT now - eay - 21-Jun-1996

# If you have perl, and it is not in /usr/local/bin, you can run

perl util/perlpath.pl /new/path

# and this will fix the paths in all the scripts.  DO NOT put

# /new/path/perl, just /new/path. The build

# environment always run scripts as 'perl perlscript.pl' but some of the

# 'applications' are easier to usr with the path fixed.

# Edit crypto/cryptlib.h, tools/c_rehash, and Makefile.ssl

# to set the install locations if you don't like

# the default location of /usr/local/ssl

# Do this by running

perl util/ssldir.pl /new/ssl/home

# if you have perl, or by hand if not.

# If things have been stuffed up with the sym links, run

make -f Makefile.ssl links

# This will re-populate lib/include with symlinks and for each

# directory, link Makefile to Makefile.ssl

# Setup the machine dependent stuff for the top level makefile

# and some select .h files

# If you don't have perl, this will bomb, in which case just edit the

# top level Makefile.ssl

./Configure 'system type'

# The 'Configure' command contains default configuration parameters

# for lots of machines.  Configure edits 5 lines in the top level Makefile

# It modifies the following values in the following files

Makefile.ssl		CC CFLAG EX_LIBS BN_MULW

crypto/des/des.h	DES_LONG

crypto/des/des_locl.h	DES_PTR

crypto/md2/md2.h	MD2_INT

crypto/rc4/rc4.h	RC4_INT

crypto/rc4/rc4_enc.c	RC4_INDEX

crypto/rc2/rc2.h	RC2_INT

crypto/bf/bf_locl.h	BF_INT

crypto/idea/idea.h	IDEA_INT

crypto/bn/bn.h		BN_LLONG (and defines one of SIXTY_FOUR_BIT,

				  SIXTY_FOUR_BIT_LONG, THIRTY_TWO_BIT,

				  SIXTEEN_BIT or EIGHT_BIT)

Please remember that all these files are actually copies of the file with

a .org extention.  So if you change crypto/des/des.h, the next time

you run Configure, it will be runover by a 'configured' version of

crypto/des/des.org.  So to make the changer the default, change the .org

files.  The reason these files have to be edited is because most of

these modifications change the size of fundamental data types.

While in theory this stuff is optional, it often makes a big

difference in performance and when using assember, it is importaint

for the 'Bignum bits' match those required by the assember code.

A warning for people using gcc with sparc cpu's.  Gcc needs the -mv8

flag to use the hardware multiply instruction which was not present in

earlier versions of the sparc CPU.  I define it by default.  If you

have an old sparc, and it crashes, try rebuilding with this flag

removed.  I am leaving this flag on by default because it makes

things run 4 times faster :-)

# clean out all the old stuff

make clean

# Do a make depend only if you have the makedepend command installed

# This is not needed but it does make things nice when developing.

make depend

# make should build everything

make

# fix up the demo certificate hash directory if it has been stuffed up.

make rehash

# test everything

make test

# install the lot

make install

# It is worth noting that all the applications are built into the one

# program, ssleay, which is then has links from the other programs

# names to it.

# The applicatons can be built by themselves, just don't define the

# 'MONOLITH' flag.  So to build the 'enc' program stand alone,

gcc -O2 -Iinclude apps/enc.c apps/apps.c libcrypto.a

# Other useful make options are

make makefile.one

# which generate a 'makefile.one' file which will build the complete

# SSLeay distribution with temp. files in './tmp' and 'installable' files

# in './out'

# Have a look at running

perl util/mk1mf.pl help

# this can be used to generate a single makefile and is about the only

# way to generate makefiles for windows.

# There is actually a final way of building SSLeay.

gcc -O2 -c -Icrypto -Iinclude crypto/crypto.c

gcc -O2 -c -Issl -Iinclude ssl/ssl.c

# and you now have the 2 libraries as single object files :-).

# If you want to use the assember code for your particular platform

# (DEC alpha/x86 are the main ones, the other assember is just the

# output from gcc) you will need to link the assember with the above generated

# object file and also do the above compile as

gcc -O2 -DBN_ASM -c -Icrypto -Iinclude crypto/crypto.c

This last option is probably the best way to go when porting to another

platform or building shared libraries.  It is not good for development so

I don't normally use it.

To build shared libararies under unix, have a look in shlib, basically 

you are on your own, but it is quite easy and all you have to do

is compile 2 (or 3) files.

For mult-threading, have a read of doc/threads.doc.  Again it is quite

easy and normally only requires some extra callbacks to be defined

by the application.

The examples for solaris and windows NT/95 are in the mt directory.

have fun

eric 25-Jun-1997

IRIX 5.x will build as a 32 bit system with mips1 assember.

IRIX 6.x will build as a 64 bit system with mips3 assember.  It conforms

to n32 standards. In theory you can compile the 64 bit assember under

IRIX 5.x but you will have to have the correct system software installed.

 program will almost certainly crash: see the original SSLeay description

 below for more details.

--------------------------------------------------------------------------------

The orignal Windows build instructions from SSLeay follow. 

Note: some of this may be out of date and no longer applicable. In particular

the Crypto_malloc_init() comment appears to be wrong: you always need to use

the same runtime library as the DLL itself.

--------------------------------------------------------------------------------

The Microsoft World.

The good news, to build SSLeay for the Microsft World

Windows 3.1 DLL's

perl Configure VC-WIN16

nmake -f ms\w31dll.mak

Windows NT/95 DLL's

perl Configure VC-WIN32

nmake -f ms\ntdll.mak

Now the bad news

All builds were done using Microsofts Visual C++ 1.52c and [45].x.

If you are a borland person, you are probably going to have to help me

finish the stuff in util/pl/BC*pl

All builds were made under Windows NT - this means long filenames, so

you may have problems under Windows 3.1 but probably not under 95.

Because file pointers don't work in DLL's under Windows 3.1 (well at

least stdin/stdout don't and I don't like having to differentiate

between these and other file pointers), I now use the BIO file-pointer

module, which needs to be linked into your application.  You can either

use the memory buffer BIO for IO, or compile bss_file.c into your

application, it is in the apps directory and is just a copy of

crypto/buffer/bss_file.c with #define APPS_WIN16 added.

I have not yet automated the makefile to automatically copy it into 'out'

for a win 3.1 build....

All callbacks passed into SSLeay for Windows 3.1 need to be of type

_far _loadds.

I don't support building with the pascal calling convention.

The DLL and static builds are large memory model.

To build static libraries for NT/95 or win 3.1

perl util/mk1mf.pl VC-WIN32 > mf-stat.nt

perl util/mk1mf.pl VC-WIN16 > mf-stat.w31

for DLL's

perl util/mk1mf.pl dll VC-WIN32	> mf-dll.nt

perl util/mk1mf.pl dll VC-WIN16 > mf-dll.w31

Again you will notice that if you dont have perl, you cannot do this.

Now the next importaint issue.  Running Configure!

I have small assember code files for critical big number library operation

in crypto/bn/asm.  There is, asm code, object files and uuencode

object files.  They are

x86nt32.asm	- 32bit flat memory model assember - suitable Win32

x86w16.asm	- 16bit assember - used in the msdos build.

x86w32.asm	- 32bit assember, win 3.1 segments, used for win16 build.

If you feel compelled to build the 16bit maths routines in the windows 3.1

build,

perl Configure VC-W31-16

perl util/mk1mf.pl dll VC-W31-16 > mf-dll.w31

If you hate assember and don't want anything to do with it,

perl util/mk1mf.pl no-asm VC-WIN16 > mf-dll.w31

will work for any of the makefile generations.

There are more options to mk1mf.pl but these all leave the temporary

files in 'tmp' and the output files in 'out' by default.

The NT build is done for console mode.

The Windows 3.1 version of SSLeay uses quickwin, the interface is ugly

but it is better than nothing.  If you want ugly, try doing anything

that involves getting a password.  I decided to be ugly instead of

echoing characters.  For Windows 3.1 I would just sugest using the

msdos version of the ssleay application for command line work.

The QuickWin build is primarily for testing.

For both NT and Windows 3.1, I have not written the code so that

s_client, s_server can take input from the keyboard.  You can happily

start applications up in separate windows, watch them handshake, and then sit

there for-ever.  I have not had the time to get this working, and I've

been able to test things from a unix box to the NT box :-).

Try running ssleay s_server on the windows box

(with either -cert ../apps/server.pem -www)

and run ssleay s_time from another window.

This often stuffs up on Windows 3.1, but I'm not worried since this is

probably a problem with my demo applications, not the libraries.

After a build of one of the version of microsoft SSLeay,

'cd ms' and then run 'test'.  This should check everything out and

even does a trial run of generating certificates.

'test.bat' requires that perl be install, you be in the ms directory

(not the test directory, thats for unix so stay out :-) and that the

build output directory be ../out 

On a last note, you will probably get division by zero errors and

stuff after a build.  This is due to your own inability to follow

instructions :-).

The reasons for the problem is probably one of the following.

1)	You did not run Configure.  This is critical for windows 3.1 when

	using assember.  The values in crypto/bn/bn.h must match the

	ones requred for the assember code.  (remember that if you

	edit crypto/bn/bn.h by hand, it will be clobered the next time

	you run Configure by the contents of crypto/bn/bn.org).

	SSLeay version -o will list the compile options.

	For VC-WIN32 you need bn(64,32) or bn(32,32)

	For VC-W31-32/VC-WIN16 you need bn(32,32)

	For VC-W31-16 you need bn(32,16) or bn(16,16)

	For VC-MSDOS you need bn(32,16) or bn(16,16).

	The first number will be 2 times bigger than the second if

	BN_LLONG is defined in bn.h and the size of the second number

	depends on the 'bits' defined at the start of bn.h.  Have a

	look, it's all reasonably clear.

	If you want to start messing with 8 bit builds and things like

	that, build without the assember by re-generating a makefile

	via 'perl util/mk1mf.pl no-asm'.

2)	You tried to build under MS-DOS or Windows 3.1 using the /G3

	option.  Don't.  It is buggy (thats why you just got that

	error) and unless you want to work out which optimising flag

	to turn off, I'm not going to help you :-).  I also noticed

	that code often ran slower when compiled with /G3.

3)	Under NT/95, malloc goes stupid.  You are probably linking with

	the wrong library, there are problems if you mix the threaded

	and non-threaded libraries (due to the DLL being staticly

	linked with one and the applicaion using another.

Well hopefully thats most of the MS issues handled, see you in ssl-users :-).

eric 30-Aug-1996

SSLeay 0.6.5

For Windows 95/NT, add CRYPTO_malloc_init() to your program before any

calls to the SSLeay libraries.  This function will insert callbacks so that

the SSLeay libraries will use the same malloc(), free() and realloc() as

your application so 'problem 3)' mentioned above will go away.

There is now DES assember for Windows NT/95.  The file is

crypto/des/asm/win32.asm and replaces crypto/des/des_enc.c in the build.

There is also Blowfish assember for Windows NT/95.  The file is

crypto/bf/asm/win32.asm and replaces crypto/bf/bf_enc.c in the build.

eric 25-Jun-1997