Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenHarmony
Third Party Openssl
提交
2fdf5d7c
T
Third Party Openssl
项目概览
OpenHarmony
/
Third Party Openssl
1 年多 前同步成功
通知
10
Star
18
Fork
1
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
T
Third Party Openssl
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
提交
2fdf5d7c
编写于
1月 07, 2000
作者:
U
Ulf Möller
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Remove obsolete SSLeay instructions.
上级
1f2f9224
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
0 addition
and
288 deletion
+0
-288
INSTALL
INSTALL
+0
-135
INSTALL.W32
INSTALL.W32
+0
-153
未找到文件。
INSTALL
浏览文件 @
2fdf5d7c
...
...
@@ -249,138 +249,3 @@
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.
INSTALL.W32
浏览文件 @
2fdf5d7c
...
...
@@ -168,156 +168,3 @@
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
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录