mirrors/openssl
0
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-30 21:44:16 +08:00
Code Issues Packages Projects Releases Wiki Activity
774530f412
openssl/Makefile.org

556 lines
18 KiB
Makefile
Raw Normal View History

Remove obsolete references to SSLeay and change default PLATFORM from "FreeBSD" to the generic "dist" as it's done implicitly by "make dist".
1999-03-22 22:45:08 +08:00
##
## Makefile for OpenSSL
##
Linux shared libraries.
1999-04-29 00:16:31 +08:00
VERSION=
MAJOR=
MINOR=
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
SHLIB_VERSION_NUMBER=
SHLIB_VERSION_HISTORY=
SHLIB_MAJOR=
SHLIB_MINOR=
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
SHLIB_EXT=
Remove obsolete references to SSLeay and change default PLATFORM from "FreeBSD" to the generic "dist" as it's done implicitly by "make dist".
1999-03-22 22:45:08 +08:00
PLATFORM=dist
mk1mf.pl and mkdef.pl read OPTIONS from toplevel Makefile. Configure no longer changes files in place.
1999-05-13 18:28:14 +08:00
OPTIONS=
Allow reconfiguration. This can be useful if some source update requires that you configure again, but you don't want to reenter all those configuration arguments again.
2000-08-17 18:23:45 +08:00
CONFIGURE_ARGS=
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
SHLIB_TARGET=
Support INSTALL_PREFIX for packagers. Submitted by: Reviewed by: PR:
1999-04-30 05:52:08 +08:00
# INSTALL_PREFIX is for package builders so that they can configure
# for, say, /usr/ and yet have everything installed to /tmp/somedir/usr/.
# Normally it is left empty.
INSTALL_PREFIX=
New Configure option --openssldir to replace util/ssldir.pl.
1999-04-25 06:59:36 +08:00
INSTALLTOP=/usr/local/ssl
# Do not edit this manually. Use Configure --openssldir=DIR do change this!
OPENSSLDIR=/usr/local/ssl
Remove obsolete references to SSLeay and change default PLATFORM from "FreeBSD" to the generic "dist" as it's done implicitly by "make dist".
1999-03-22 22:45:08 +08:00
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
# NO_IDEA - Define to build without the IDEA algorithm
# NO_RC4 - Define to build without the RC4 algorithm
# NO_RC2 - Define to build without the RC2 algorithm
# THREADS - Define when building with threads, you will probably also need any
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
# system defines as well, i.e. _REENTERANT for Solaris 2.[34]
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
# TERMIO - Define the termio terminal subsystem, needed if sgtty is missing.
# TERMIOS - Define the termios terminal subsystem, Silicon Graphics.
# LONGCRYPT - Define to use HPUX 10.x's long password modification to crypt(3).
# DEVRANDOM - Give this the value of the 'random device' if your OS supports
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
# one. 32 bytes will be read from this when the random
# number generator is initalised.
SSL_ALLOW_ENULL was renamed to SSL_FORBID_ENULL some time ago by Ben.
1999-04-13 19:01:44 +08:00
# SSL_FORBID_ENULL - define if you want the server to be not able to use the
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
# NULL encryption ciphers.
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
#
# LOCK_DEBUG - turns on lots of lock debug output :-)
# REF_CHECK - turn on some xyz_free() assertions.
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
# REF_PRINT - prints some stuff on structure free.
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
# CRYPTO_MDEBUG - turns on my 'memory leak' detecting stuff
# MFUNC - Make all Malloc/Free/Realloc calls call
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
# CRYPTO_malloc/CRYPTO_free/CRYPTO_realloc which can be setup to
# call application defined callbacks via CRYPTO_set_mem_functions()
# MD5_ASM needs to be defined to use the x86 assembler for MD5
# SHA1_ASM needs to be defined to use the x86 assembler for SHA1
# RMD160_ASM needs to be defined to use the x86 assembler for RIPEMD160
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 19:00:56 +08:00
# Do not define B_ENDIAN or L_ENDIAN if 'unsigned long' == 8. It must
# equal 4.
# PKCS1_CHECK - pkcs1 tests.
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Deal with generated files.
1998-12-29 05:58:19 +08:00
CC= gcc
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 19:00:56 +08:00
#CFLAG= -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -Wuninitialized -DSHA1_ASM -DMD5_ASM -DRMD160_ASM
Deal with generated files.
1998-12-29 05:58:19 +08:00
CFLAG= -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM
New Configure option no-<cipher> (rsa, idea, rc5, ...).
1999-04-27 09:14:46 +08:00
DEPFLAG=
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
PEX_LIBS= -L. -L.. -L../.. -L../../..
Various cleanups and fixed by Marc and Ralf to start the OpenTLS project
1998-12-22 23:04:48 +08:00
EX_LIBS=
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
AR=ar r
New Makefile variables $(RANLIB) and $(PERL).
1999-04-01 20:34:33 +08:00
RANLIB= ranlib
PERL= perl
Make it possible to have differing tar versions.
2000-02-24 09:59:55 +08:00
TAR= tar
I'm using GNU tar...
2000-09-21 15:15:52 +08:00
TARFLAGS= --no-recursion
Make all configuration macros available for application by making sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
2001-02-20 00:06:34 +08:00
MAKEDEPPROG=makedepend
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 19:00:56 +08:00
# Set BN_ASM to bn_asm.o if you want to use the C version
BN_ASM= bn_asm.o
#BN_ASM= bn_asm.o
#BN_ASM= asm/bn86-elf.o # elf, linux-elf
#BN_ASM= asm/bn86-sol.o # solaris
#BN_ASM= asm/bn86-out.o # a.out, FreeBSD
#BN_ASM= asm/bn86bsdi.o # bsdi
#BN_ASM= asm/alpha.o # DEC Alpha
#BN_ASM= asm/pa-risc2.o # HP-UX PA-RISC
#BN_ASM= asm/r3000.o # SGI MIPS cpu
#BN_ASM= asm/sparc.o # Sun solaris/SunOS
#BN_ASM= asm/bn-win32.o # Windows 95/NT
#BN_ASM= asm/x86w16.o # 16 bit code for Windows 3.1/DOS
#BN_ASM= asm/x86w32.o # 32 bit code for Windows 3.1
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
New option to generate 80386 code.
1999-03-31 20:38:27 +08:00
# For x86 assembler: Set PROCESSOR to 386 if you want to support
# the 80386.
PROCESSOR=
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
# Set DES_ENC to des_enc.o if you want to use the C version
#There are 4 x86 assember options.
Deal with generated files.
1998-12-29 05:58:19 +08:00
DES_ENC= asm/dx86-out.o asm/yx86-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#DES_ENC= des_enc.o fcrypt_b.o # C
#DES_ENC= asm/dx86-elf.o asm/yx86-elf.o # elf
#DES_ENC= asm/dx86-sol.o asm/yx86-sol.o # solaris
#DES_ENC= asm/dx86-out.o asm/yx86-out.o # a.out, FreeBSD
#DES_ENC= asm/dx86bsdi.o asm/yx86bsdi.o # bsdi
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
# Set BF_ENC to bf_enc.o if you want to use the C version
#There are 4 x86 assember options.
Deal with generated files.
1998-12-29 05:58:19 +08:00
BF_ENC= asm/bx86-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#BF_ENC= bf_enc.o
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
#BF_ENC= asm/bx86-elf.o # elf
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#BF_ENC= asm/bx86-sol.o # solaris
#BF_ENC= asm/bx86-out.o # a.out, FreeBSD
#BF_ENC= asm/bx86bsdi.o # bsdi
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
# Set CAST_ENC to c_enc.o if you want to use the C version
#There are 4 x86 assember options.
Deal with generated files.
1998-12-29 05:58:19 +08:00
CAST_ENC= asm/cx86-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#CAST_ENC= c_enc.o
#CAST_ENC= asm/cx86-elf.o # elf
#CAST_ENC= asm/cx86-sol.o # solaris
#CAST_ENC= asm/cx86-out.o # a.out, FreeBSD
#CAST_ENC= asm/cx86bsdi.o # bsdi
# Set RC4_ENC to rc4_enc.o if you want to use the C version
#There are 4 x86 assember options.
Deal with generated files.
1998-12-29 05:58:19 +08:00
RC4_ENC= asm/rx86-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#RC4_ENC= rc4_enc.o
#RC4_ENC= asm/rx86-elf.o # elf
#RC4_ENC= asm/rx86-sol.o # solaris
#RC4_ENC= asm/rx86-out.o # a.out, FreeBSD
#RC4_ENC= asm/rx86bsdi.o # bsdi
# Set RC5_ENC to rc5_enc.o if you want to use the C version
#There are 4 x86 assember options.
Deal with generated files.
1998-12-29 05:58:19 +08:00
RC5_ENC= asm/r586-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#RC5_ENC= rc5_enc.o
#RC5_ENC= asm/r586-elf.o # elf
#RC5_ENC= asm/r586-sol.o # solaris
#RC5_ENC= asm/r586-out.o # a.out, FreeBSD
#RC5_ENC= asm/r586bsdi.o # bsdi
# Also need MD5_ASM defined
Deal with generated files.
1998-12-29 05:58:19 +08:00
MD5_ASM_OBJ= asm/mx86-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#MD5_ASM_OBJ= asm/mx86-elf.o # elf
#MD5_ASM_OBJ= asm/mx86-sol.o # solaris
#MD5_ASM_OBJ= asm/mx86-out.o # a.out, FreeBSD
#MD5_ASM_OBJ= asm/mx86bsdi.o # bsdi
# Also need SHA1_ASM defined
Deal with generated files.
1998-12-29 05:58:19 +08:00
SHA1_ASM_OBJ= asm/sx86-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#SHA1_ASM_OBJ= asm/sx86-elf.o # elf
#SHA1_ASM_OBJ= asm/sx86-sol.o # solaris
#SHA1_ASM_OBJ= asm/sx86-out.o # a.out, FreeBSD
#SHA1_ASM_OBJ= asm/sx86bsdi.o # bsdi
# Also need RMD160_ASM defined
Deal with generated files.
1998-12-29 05:58:19 +08:00
RMD160_ASM_OBJ= asm/rm86-out.o
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
#RMD160_ASM_OBJ= asm/rm86-elf.o # elf
#RMD160_ASM_OBJ= asm/rm86-sol.o # solaris
#RMD160_ASM_OBJ= asm/rm86-out.o # a.out, FreeBSD
#RMD160_ASM_OBJ= asm/rm86bsdi.o # bsdi
First tentative impementation of Kerberos 5 cryptos and keys for SSL/TLS. Implemented by Vern Staats <staatsvr@asc.hpc.mil>, further hacked and distributed by Jeffrey Altman <jaltnab@columbia.edu>
2000-12-01 06:53:34 +08:00
# KRB5 stuff
KRB5_INCLUDES=
LIBKRB5=
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
# When we're prepared to use shared libraries in the programs we link here
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
# we might set SHLIB_MARK to '$(SHARED_LIBS)'.
SHLIB_MARK=
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
Remove references to RSAref. The glue library is but a memory to fade away now...
2000-11-09 01:51:37 +08:00
DIRS= crypto ssl $(SHLIB_MARK) apps test tools
Linux shared libraries.
1999-04-29 00:16:31 +08:00
SHLIBDIRS= crypto ssl
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
# dirs in crypto to build
SDIRS= \
MD4 implemented. Assar Westerlund provided the digest code itself and the test utility, I added the bits to get a EVP interface, the command line utility and the speed test
2000-08-14 22:05:53 +08:00
md2 md4 md5 sha mdc2 hmac ripemd \
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
des rc2 rc4 rc5 idea bf cast \
Move ec.h to ec2.h because it is not compatible with what we will use. Add EC vaporware: change relevant Makefiles and add some empty source files. "make update".
2001-03-06 04:13:37 +08:00
bn ec rsa dsa dh dso engine rijndael \
More X509 V3 stuff. Add support for extensions in the 'req' application so that: openssl req -x509 -new -out cert.pem will take extensions from openssl.cnf a sample for a CA is included. Also change the directory order so pem is nearer the end. Otherwise 'make links' wont work because pem.h can't be built.
1999-01-25 09:09:21 +08:00
buffer bio stack lhash rand err objects \
The majority of the OCSP code from CertCo.
2000-10-27 19:05:35 +08:00
evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp ocsp
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
For a long time, I've wanted to be able to easily run one or a few individual tests. I finally got myself to implement it...
2000-11-13 04:24:30 +08:00
# tests to perform. "alltests" is a special word indicating that all tests
# should be performed.
TESTS = alltests
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
MAKEFILE= Makefile.ssl
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
MAKE= make -f Makefile.ssl
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Install manpages below OPENSSLDIR (I think it was meant to be this way?). New variable for man directory.
2000-02-16 02:34:46 +08:00
MANDIR=$(OPENSSLDIR)/man
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
MAN1=1
MAN3=3
SHELL=/bin/sh
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
TOP= .
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
ONEDIRS=out tmp
VMS support. Submitted by: Richard Levitte <richard@levitte.org>
1999-05-13 19:37:32 +08:00
EDIRS= times doc bugs util include certs ms shlib mt demos perl sf dep VMS
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
WDIRS= windows
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
LIBS= libcrypto.a libssl.a
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
SHARED_CRYPTO=libcrypto$(SHLIB_EXT)
SHARED_SSL=libssl$(SHLIB_EXT)
SHARED_LIBS=
SHARED_LIBS_LINK_EXTS=
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
GENERAL= Makefile
*** empty log message ***
1998-12-23 15:58:53 +08:00
BASENAME= openssl
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
NAME= $(BASENAME)-$(VERSION)
TARFILE= $(NAME).tar
WTARFILE= $(NAME)-win.tar
Make all configuration macros available for application by making sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
2001-02-20 00:06:34 +08:00
EXHEADER= e_os2.h
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
HEADER= e_os.h
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
# When we're prepared to use shared libraries in the programs we link here
# we might remove 'clean-shared' from the targets to perform at this stage
all: clean-shared Makefile.ssl sub_all
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
sub_all:
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
@for i in $(DIRS); \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making all in $$i..." && \
First tentative impementation of Kerberos 5 cryptos and keys for SSL/TLS. Implemented by Vern Staats <staatsvr@asc.hpc.mil>, further hacked and distributed by Jeffrey Altman <jaltnab@columbia.edu>
2000-12-01 06:53:34 +08:00
$(MAKE) CC='${CC}' PLATFORM='${PLATFORM}' CFLAG='${CFLAG}' SDIRS='$(SDIRS)' INSTALLTOP='${INSTALLTOP}' PEX_LIBS='${PEX_LIBS}' EX_LIBS='${EX_LIBS}' BN_ASM='${BN_ASM}' DES_ENC='${DES_ENC}' BF_ENC='${BF_ENC}' CAST_ENC='${CAST_ENC}' RC4_ENC='${RC4_ENC}' RC5_ENC='${RC5_ENC}' SHA1_ASM_OBJ='${SHA1_ASM_OBJ}' MD5_ASM_OBJ='${MD5_ASM_OBJ}' RMD160_ASM_OBJ='${RMD160_ASM_OBJ}' AR='${AR}' PROCESSOR='${PROCESSOR}' PERL='${PERL}' RANLIB='${RANLIB}' KRB5_INCLUDES='${KRB5_INCLUDES}' LIBKRB5='${LIBKRB5}' all ) || exit 1; \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
else \
$(MAKE) $$i; \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
fi; \
done; \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if echo "$(DIRS)" | \
It seems like grep isn't as capable as I thought on some Unix systems. Use egrep instead.
2000-10-23 00:46:47 +08:00
egrep '(^| )(crypto|ssl)( |$$)' > /dev/null 2>&1 && \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
[ -n "$(SHARED_LIBS)" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
$(MAKE) $(SHARED_LIBS); \
fi
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
libcrypto$(SHLIB_EXT): libcrypto.a
Avoid loops, and make sure that it's possible to still build shared libraries even if the "shared" configuration option wasn't chosen.
2000-07-25 04:36:46 +08:00
@if [ "$(SHLIB_TARGET)" != "" ]; then \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
$(MAKE) SHLIBDIRS=crypto build-shared; \
Avoid loops, and make sure that it's possible to still build shared libraries even if the "shared" configuration option wasn't chosen.
2000-07-25 04:36:46 +08:00
else \
echo "There's no support for shared libraries on this platform" >&2; \
fi
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
libssl$(SHLIB_EXT): libcrypto$(SHLIB_EXT) libssl.a
Avoid loops, and make sure that it's possible to still build shared libraries even if the "shared" configuration option wasn't chosen.
2000-07-25 04:36:46 +08:00
@if [ "$(SHLIB_TARGET)" != "" ]; then \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
$(MAKE) SHLIBDIRS=ssl SHLIBDEPS='-L. -lcrypto' build-shared; \
Avoid loops, and make sure that it's possible to still build shared libraries even if the "shared" configuration option wasn't chosen.
2000-07-25 04:36:46 +08:00
else \
echo "There's no support for shared libraries on this platform" >&2; \
fi
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
clean-shared:
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
@for i in $(SHLIBDIRS); do \
if [ -n "$(SHARED_LIBS_LINK_EXTS)" ]; then \
tmp="$(SHARED_LIBS_LINK_EXTS)"; \
for j in $${tmp:-x}; do \
( set -x; rm -f lib$$i$$j ); \
done; \
fi; \
( set -x; rm -f lib$$i$(SHLIB_EXT) ); \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
done
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
link-shared:
@for i in $(SHLIBDIRS); do \
prev=lib$$i$(SHLIB_EXT); \
if [ -n "$(SHARED_LIBS_LINK_EXTS)" ]; then \
tmp="$(SHARED_LIBS_LINK_EXTS)"; \
for j in $${tmp:-x}; do \
( set -x; ln -s -f $$prev lib$$i$$j ); \
prev=lib$$i$$j; \
done; \
fi; \
done
build-shared: clean-shared do_$(SHLIB_TARGET) link-shared
do_bsd-gcc-shared: linux-shared
do_linux-shared:
A few corrections with the shared library support: 1. make sure libssl.so becomes dependent on libcrypto.so 2. correct a number of silly bugs in the solaris-shared target, and make sure lib*.so also depends on libc.so.
2000-08-02 11:03:17 +08:00
libs='${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
( set -x; ${CC} -shared -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Make sure that shared libraries get the internal name engine with the full version number and not just 0. This should mark the shared libraries as not backward compatible. Of course, this should be changed again when we can guarantee backward binary compatibility.
2000-11-06 14:52:47 +08:00
-Wl,-S,-soname=lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Linux shared libraries.
1999-04-29 00:16:31 +08:00
-Wl,--whole-archive lib$$i.a \
It's probably a good idea to make the shared libraries depend in EX_LIBS.
2000-08-02 11:52:49 +08:00
-Wl,--no-whole-archive $$libs ${EX_LIBS} -lc ) || exit 1; \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
libs="$$libs -L. -l$$i"; \
A few corrections with the shared library support: 1. make sure libssl.so becomes dependent on libcrypto.so 2. correct a number of silly bugs in the solaris-shared target, and make sure lib*.so also depends on libc.so.
2000-08-02 11:03:17 +08:00
done
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
# This assumes that GNU utilities are *not* used
Rename true64 to the correct tru64. Suggested by Albert Chin-A-Young <china@thewrittenword.com>
2000-11-01 07:39:08 +08:00
do_tru64-shared:
A few corrections with the shared library support: 1. make sure libssl.so becomes dependent on libcrypto.so 2. correct a number of silly bugs in the solaris-shared target, and make sure lib*.so also depends on libc.so.
2000-08-02 11:03:17 +08:00
libs='${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
( set -x; ${CC} -shared -no_archive -o lib$$i.so \
-set_version "${SHLIB_VERSION_HISTORY}${SHLIB_VERSION_NUMBER}" \
It's probably a good idea to make the shared libraries depend in EX_LIBS.
2000-08-02 11:52:49 +08:00
-all lib$$i.a -none $$libs ${EX_LIBS} -lc ) || exit 1; \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
libs="$$libs -L. -l$$i"; \
A few corrections with the shared library support: 1. make sure libssl.so becomes dependent on libcrypto.so 2. correct a number of silly bugs in the solaris-shared target, and make sure lib*.so also depends on libc.so.
2000-08-02 11:03:17 +08:00
done
Linux shared libraries.
1999-04-29 00:16:31 +08:00
Add support for solaris shared libraries, currently just experimental (there's no way to get it through configuration yet).
2000-07-25 04:50:21 +08:00
# This assumes that GNU utilities are *not* used
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
do_solaris-shared:
A few corrections with the shared library support: 1. make sure libssl.so becomes dependent on libcrypto.so 2. correct a number of silly bugs in the solaris-shared target, and make sure lib*.so also depends on libc.so.
2000-08-02 11:03:17 +08:00
libs='${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
Add support for solaris shared libraries, currently just experimental (there's no way to get it through configuration yet).
2000-07-25 04:50:21 +08:00
( set -x; ${CC} -G -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Make sure that shared libraries get the internal name engine with the full version number and not just 0. This should mark the shared libraries as not backward compatible. Of course, this should be changed again when we can guarantee backward binary compatibility.
2000-11-06 14:52:47 +08:00
-h lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
It's probably a good idea to make the shared libraries depend in EX_LIBS.
2000-08-02 11:52:49 +08:00
-z allextract lib$$i.a $$libs ${EX_LIBS} -lc ) || exit 1; \
Add support for solaris shared libraries, currently just experimental (there's no way to get it through configuration yet).
2000-07-25 04:50:21 +08:00
libs="$$libs -L. -l$$i"; \
A few corrections with the shared library support: 1. make sure libssl.so becomes dependent on libcrypto.so 2. correct a number of silly bugs in the solaris-shared target, and make sure lib*.so also depends on libc.so.
2000-08-02 11:03:17 +08:00
done
Add support for solaris shared libraries, currently just experimental (there's no way to get it through configuration yet).
2000-07-25 04:50:21 +08:00
Add support for shared libraries under Irix. Submitted by Albert Chin-A-Young <china@thewrittenword.com>
2000-11-01 08:05:04 +08:00
# This assumes that GNU utilities are *not* used
do_irix-shared:
libs='${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( set -x; ${CC} -shared -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Make sure that shared libraries get the internal name engine with the full version number and not just 0. This should mark the shared libraries as not backward compatible. Of course, this should be changed again when we can guarantee backward binary compatibility.
2000-11-06 14:52:47 +08:00
-Wl,-soname,lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Add support for shared libraries under Irix. Submitted by Albert Chin-A-Young <china@thewrittenword.com>
2000-11-01 08:05:04 +08:00
-all lib$$i.a $$libs ${EX_LIBS} -lc) || exit 1; \
libs="$$libs -L. -l$$i"; \
done
Add what's needed to get shared libraries on HP-UX. N.B.: This has not been tested at all, that's my next step.
2000-10-22 05:24:11 +08:00
# This assumes that GNU utilities are *not* used
HP-UX shared libraries do not build any longer, as EX_LIBS contains "-Wl,+s" instead of +s: * Hardcoded necessary references to -ldld/-ldl into the build rules and removed EX_LIBS. HP-UX records the pathnames of dependent libraries when the shared libs are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with "./" not being resolvable when running an application linked against -lssl: * Build libssl without explicit reference to libcrypto, applications will be linked with "-lssl -lcrypto" anyway. Document these informations in Makefile.org.
2000-11-13 22:40:07 +08:00
# HP-UX includes the full pathname of libs we depend on, so we would get
# ./libcrypto (with ./ as path information) compiled into libssl, hence
# we omit the SHLIBDEPS. Applications must be linked with -lssl -lcrypto
# anyway.
# The object modules are loaded from lib$i.a using the undocumented -Fl
# option.
#
# WARNING: Until DSO is fixed to support a search path, we support SHLIB_PATH
# by temporarily specifying "+s"!
#
Add what's needed to get shared libraries on HP-UX. N.B.: This has not been tested at all, that's my next step.
2000-10-22 05:24:11 +08:00
do_hpux-shared:
HP-UX shared libraries do not build any longer, as EX_LIBS contains "-Wl,+s" instead of +s: * Hardcoded necessary references to -ldld/-ldl into the build rules and removed EX_LIBS. HP-UX records the pathnames of dependent libraries when the shared libs are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with "./" not being resolvable when running an application linked against -lssl: * Build libssl without explicit reference to libcrypto, applications will be linked with "-lssl -lcrypto" anyway. Document these informations in Makefile.org.
2000-11-13 22:40:07 +08:00
for i in ${SHLIBDIRS}; do \
When building shared libraries on HP-UX 10.20 and HP-UX 11.00 (32bit), ld warns that -Fl "may not be supported in future releases". We know that, and are doing things in HP-UX 11 (64bit), so turn off that warning with +vnocompatwarnings.
2000-10-23 05:37:39 +08:00
( set -x; /usr/ccs/bin/ld +vnocompatwarnings \
HP-UX shared libraries do not build any longer, as EX_LIBS contains "-Wl,+s" instead of +s: * Hardcoded necessary references to -ldld/-ldl into the build rules and removed EX_LIBS. HP-UX records the pathnames of dependent libraries when the shared libs are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with "./" not being resolvable when running an application linked against -lssl: * Build libssl without explicit reference to libcrypto, applications will be linked with "-lssl -lcrypto" anyway. Document these informations in Makefile.org.
2000-11-13 22:40:07 +08:00
-b -z +s \
-o lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Add what's needed to get shared libraries on HP-UX. N.B.: This has not been tested at all, that's my next step.
2000-10-22 05:24:11 +08:00
+h lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR} \
HP-UX shared libraries do not build any longer, as EX_LIBS contains "-Wl,+s" instead of +s: * Hardcoded necessary references to -ldld/-ldl into the build rules and removed EX_LIBS. HP-UX records the pathnames of dependent libraries when the shared libs are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with "./" not being resolvable when running an application linked against -lssl: * Build libssl without explicit reference to libcrypto, applications will be linked with "-lssl -lcrypto" anyway. Document these informations in Makefile.org.
2000-11-13 22:40:07 +08:00
-Fl lib$$i.a -ldld -lc ) || exit 1; \
Add what's needed to get shared libraries on HP-UX. N.B.: This has not been tested at all, that's my next step.
2000-10-22 05:24:11 +08:00
done
# This assumes that GNU utilities are *not* used
HP-UX shared libraries do not build any longer, as EX_LIBS contains "-Wl,+s" instead of +s: * Hardcoded necessary references to -ldld/-ldl into the build rules and removed EX_LIBS. HP-UX records the pathnames of dependent libraries when the shared libs are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with "./" not being resolvable when running an application linked against -lssl: * Build libssl without explicit reference to libcrypto, applications will be linked with "-lssl -lcrypto" anyway. Document these informations in Makefile.org.
2000-11-13 22:40:07 +08:00
# HP-UX includes the full pathname of libs we depend on, so we would get
# ./libcrypto (with ./ as path information) compiled into libssl, hence
# we omit the SHLIBDEPS. Applications must be linked with -lssl -lcrypto
# anyway.
#
# HP-UX in 64bit mode has "+s" enabled by default; it will search for
# shared libraries along LD_LIBRARY_PATH _and_ SHLIB_PATH.
#
Add what's needed to get shared libraries on HP-UX. N.B.: This has not been tested at all, that's my next step.
2000-10-22 05:24:11 +08:00
do_hpux64-shared:
HP-UX shared libraries do not build any longer, as EX_LIBS contains "-Wl,+s" instead of +s: * Hardcoded necessary references to -ldld/-ldl into the build rules and removed EX_LIBS. HP-UX records the pathnames of dependent libraries when the shared libs are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with "./" not being resolvable when running an application linked against -lssl: * Build libssl without explicit reference to libcrypto, applications will be linked with "-lssl -lcrypto" anyway. Document these informations in Makefile.org.
2000-11-13 22:40:07 +08:00
for i in ${SHLIBDIRS}; do \
( set -x; /usr/ccs/bin/ld -b -z \
-o lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Add what's needed to get shared libraries on HP-UX. N.B.: This has not been tested at all, that's my next step.
2000-10-22 05:24:11 +08:00
+h lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR} \
HP-UX shared libraries do not build any longer, as EX_LIBS contains "-Wl,+s" instead of +s: * Hardcoded necessary references to -ldld/-ldl into the build rules and removed EX_LIBS. HP-UX records the pathnames of dependent libraries when the shared libs are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with "./" not being resolvable when running an application linked against -lssl: * Build libssl without explicit reference to libcrypto, applications will be linked with "-lssl -lcrypto" anyway. Document these informations in Makefile.org.
2000-11-13 22:40:07 +08:00
+forceload lib$$i.a -ldl -lc ) || exit 1; \
Add what's needed to get shared libraries on HP-UX. N.B.: This has not been tested at all, that's my next step.
2000-10-22 05:24:11 +08:00
done
Make sure people know when they need to rebuild the Makefile.
1999-01-25 02:15:00 +08:00
Makefile.ssl: Makefile.org
Print a little bit more information
1999-03-22 22:38:33 +08:00
@echo "Makefile.ssl is older than Makefile.org."
Make the perl module compile and eliminate some of the warnings. Still doesn't work (the destructor on BIO and SSL is called immediately after creating the object. Why that??)
1999-07-23 00:10:31 +08:00
@echo "Reconfigure the source tree (via './config' or 'perl Configure'), please."
Make sure people know when they need to rebuild the Makefile.
1999-01-25 02:15:00 +08:00
@false
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 19:00:56 +08:00
libclean:
General source tree makefile cleanups: Made `making xxx in yyy...' display consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally cleaned up the `make links' target: Remove unnecessary semicolons, subsequent redundant removes, inline point.sh into mklink.sh to speed processing and no longer clutter the display with confusing stuff. Instead only the actually done links are displayed.
1999-03-06 20:32:06 +08:00
rm -f *.a */lib */*/lib
Import of old SSLeay release: SSLeay 0.9.1b (unreleased)
1998-12-21 19:00:56 +08:00
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
clean:
In "make clean", delete files created by "make report".
2000-02-25 22:34:55 +08:00
rm -f shlib/*.o *.o core a.out fluff *.map rehash.time testlog make.log cctest cctest.c
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
@for i in $(DIRS) ;\
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making clean in $$i..." && \
$(MAKE) SDIRS='${SDIRS}' clean ) || exit 1; \
rm -f $(LIBS); \
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done;
General source tree makefile cleanups: Made `making xxx in yyy...' display consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally cleaned up the `make links' target: Remove unnecessary semicolons, subsequent redundant removes, inline point.sh into mklink.sh to speed processing and no longer clutter the display with confusing stuff. Instead only the actually done links are displayed.
1999-03-06 20:32:06 +08:00
rm -f *.a *.o speed.* *.map *.so .pure core
rm -f $(TARFILE)
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
@for i in $(ONEDIRS) ;\
do \
General source tree makefile cleanups: Made `making xxx in yyy...' display consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally cleaned up the `make links' target: Remove unnecessary semicolons, subsequent redundant removes, inline point.sh into mklink.sh to speed processing and no longer clutter the display with confusing stuff. Instead only the actually done links are displayed.
1999-03-06 20:32:06 +08:00
rm -fr $$i/*; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done
makefile.one: files
New Makefile variables $(RANLIB) and $(PERL).
1999-04-01 20:34:33 +08:00
$(PERL) util/mk1mf.pl >makefile.one; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
sh util/do_ms.sh
Bad dependencies.
1999-04-08 23:19:36 +08:00
files:
New Makefile variables $(RANLIB) and $(PERL).
1999-04-01 20:34:33 +08:00
$(PERL) $(TOP)/util/files.pl Makefile.ssl > $(TOP)/MINFO
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
@for i in $(DIRS) ;\
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making 'files' in $$i..." && \
$(MAKE) SDIRS='${SDIRS}' PERL='${PERL}' files ) || exit 1; \
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done;
links:
General source tree makefile cleanups: Made `making xxx in yyy...' display consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally cleaned up the `make links' target: Remove unnecessary semicolons, subsequent redundant removes, inline point.sh into mklink.sh to speed processing and no longer clutter the display with confusing stuff. Instead only the actually done links are displayed.
1999-03-06 20:32:06 +08:00
@$(TOP)/util/point.sh Makefile.ssl Makefile
mkdir -p is not fully portable (according to Marc Crispin, NeXTstep creates a directory called -p); now mkdir-p.pl does its job.
1999-06-07 21:33:50 +08:00
@$(PERL) $(TOP)/util/mkdir-p.pl include/openssl
e_os.h does not belong with the exported headers. Do not put it there and make all files the depend on it include it without prefixing it with openssl/. This means that all Makefiles will have $(TOP) as one of the include directories.
2001-02-22 22:45:02 +08:00
@$(PERL) $(TOP)/util/mklink.pl include/openssl $(EXHEADER)
General source tree makefile cleanups: Made `making xxx in yyy...' display consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally cleaned up the `make links' target: Remove unnecessary semicolons, subsequent redundant removes, inline point.sh into mklink.sh to speed processing and no longer clutter the display with confusing stuff. Instead only the actually done links are displayed.
1999-03-06 20:32:06 +08:00
@for i in $(DIRS); do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making links in $$i..." && \
First tentative impementation of Kerberos 5 cryptos and keys for SSL/TLS. Implemented by Vern Staats <staatsvr@asc.hpc.mil>, further hacked and distributed by Jeffrey Altman <jaltnab@columbia.edu>
2000-12-01 06:53:34 +08:00
$(MAKE) CC='${CC}' PLATFORM='${PLATFORM}' CFLAG='${CFLAG}' SDIRS='$(SDIRS)' INSTALLTOP='${INSTALLTOP}' PEX_LIBS='${PEX_LIBS}' EX_LIBS='${EX_LIBS}' BN_ASM='${BN_ASM}' DES_ENC='${DES_ENC}' BF_ENC='${BF_ENC}' CAST_ENC='${CAST_ENC}' RC4_ENC='${RC4_ENC}' RC5_ENC='${RC5_ENC}' SHA1_ASM_OBJ='${SHA1_ASM_OBJ}' MD5_ASM_OBJ='${MD5_ASM_OBJ}' RMD160_ASM_OBJ='${RMD160_ASM_OBJ}' AR='${AR}' PERL='${PERL}' KRB5_INCLUDES='${KRB5_INCLUDES}' LIBKRB5='${LIBKRB5}' links ) || exit 1; \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done;
dclean:
General source tree makefile cleanups: Made `making xxx in yyy...' display consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally cleaned up the `make links' target: Remove unnecessary semicolons, subsequent redundant removes, inline point.sh into mklink.sh to speed processing and no longer clutter the display with confusing stuff. Instead only the actually done links are displayed.
1999-03-06 20:32:06 +08:00
rm -f *.bak
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
@for i in $(DIRS) ;\
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making dclean in $$i..." && \
$(MAKE) SDIRS='${SDIRS}' PERL='${PERL}' dclean ) || exit 1; \
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done;
Implement MD5-based "apr1" password hash.
2000-02-12 00:25:44 +08:00
rehash: rehash.time
rehash.time: certs
Fix c_rehash script, add -fingerprint option to crl.
2000-05-18 08:33:00 +08:00
@(OPENSSL="`pwd`/apps/openssl"; export OPENSSL; $(PERL) tools/c_rehash certs)
Corrections.
2000-02-12 01:18:50 +08:00
touch rehash.time
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
test: tests
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Do make rehash automatically at make test.
1999-04-29 00:14:39 +08:00
tests: rehash
General source tree makefile cleanups: Made `making xxx in yyy...' display consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally cleaned up the `make links' target: Remove unnecessary semicolons, subsequent redundant removes, inline point.sh into mklink.sh to speed processing and no longer clutter the display with confusing stuff. Instead only the actually done links are displayed.
1999-03-06 20:32:06 +08:00
@(cd test && echo "testing..." && \
Pass ${PERL} down to the Makefile in sub-directory "test" in "make tests"
2001-01-11 00:43:52 +08:00
$(MAKE) CC='${CC}' CFLAG='${CFLAG}' INSTALLTOP='${INSTALLTOP}' PEX_LIBS='${PEX_LIBS}' EX_LIBS='${EX_LIBS}' BN_ASM='${BN_ASM}' DES_ENC='${DES_ENC}' BF_ENC='${BF_ENC}' CAST_ENC='${CAST_ENC}' RC4_ENC='${RC4_ENC}' RC5_ENC='${RC5_ENC}' SDIRS='${SDIRS}' SHA1_ASM_OBJ='${SHA1_ASM_OBJ}' MD5_ASM_OBJ='${MD5_ASM_OBJ}' RMD160_ASM_OBJ='${RMD160_ASM_OBJ}' AR='${AR}' PERL='${PERL}' TESTS='${TESTS}' KRB5_INCLUDES='${KRB5_INCLUDES}' LIBKRB5='${LIBKRB5}' tests );
Binary is now apps/openssl not apps/ssleay so use the new name when rehashing the test certs
1999-01-02 23:08:29 +08:00
@apps/openssl version -a
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
New make target "report" to run util/selftest.pl
2000-02-24 07:47:05 +08:00
report:
@$(PERL) util/selftest.pl
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
depend:
@for i in $(DIRS) ;\
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making dependencies $$i..." && \
Make all configuration macros available for application by making sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
2001-02-20 00:06:34 +08:00
$(MAKE) SDIRS='${SDIRS}' DEPFLAG='${DEPFLAG}' MAKEDEPPROG='${MAKEDEPPROG}' depend ) || exit 1; \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done;
lint:
@for i in $(DIRS) ;\
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making lint $$i..." && \
$(MAKE) SDIRS='${SDIRS}' lint ) || exit 1; \
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done;
tags:
@for i in $(DIRS) ;\
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i && echo "making tags $$i..." && \
$(MAKE) SDIRS='${SDIRS}' tags ) || exit 1; \
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done;
errors:
Use $(PERL) in place of hard-coded perl
2001-01-11 00:40:30 +08:00
$(PERL) util/mkerr.pl -recurse -write
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
This change will cause builds (by default) to not use different STACK structures and functions for each stack type. The previous behaviour can be enabled by configuring with the "-DDEBUG_SAFESTACK" option. This will also cause "make update" (mkdef.pl in particular) to update the libeay.num and ssleay.num symbol tables with the number of extra functions DEBUG_SAFESTACK creates. The way this change works is to accompany each DECLARE_STACK_OF() macro with a set of "#define"d versions of the sk_##type##_*** functions that ensures all the existing "type-safe" stack calls are precompiled into the underlying stack calls. The presence or abscence of the DEBUG_SAFESTACK symbol controls whether this block of "#define"s or the DECLARE_STACK_OF() macro is taking effect. The block of "#define"s is in turn generated and maintained by a perl script (util/mkstack.pl) that encompasses the block with delimiting C comments. This works in a similar way to the auto-generated error codes and, like the other such maintenance utilities, is invoked by the "make update" target. A long (but mundane) commit will follow this with the results of "make update" - this will include all the "#define" blocks for each DECLARE_STACK_OF() statement, along with stripped down libeay.num and ssleay.num files.
2000-06-01 13:13:52 +08:00
stacks:
Use $(PERL) in place of hard-coded perl
2001-01-11 00:40:30 +08:00
$(PERL) util/mkstack.pl -write
This change will cause builds (by default) to not use different STACK structures and functions for each stack type. The previous behaviour can be enabled by configuring with the "-DDEBUG_SAFESTACK" option. This will also cause "make update" (mkdef.pl in particular) to update the libeay.num and ssleay.num symbol tables with the number of extra functions DEBUG_SAFESTACK creates. The way this change works is to accompany each DECLARE_STACK_OF() macro with a set of "#define"d versions of the sk_##type##_*** functions that ensures all the existing "type-safe" stack calls are precompiled into the underlying stack calls. The presence or abscence of the DEBUG_SAFESTACK symbol controls whether this block of "#define"s or the DECLARE_STACK_OF() macro is taking effect. The block of "#define"s is in turn generated and maintained by a perl script (util/mkstack.pl) that encompasses the block with delimiting C comments. This works in a similar way to the auto-generated error codes and, like the other such maintenance utilities, is invoked by the "make update" target. A long (but mundane) commit will follow this with the results of "make update" - this will include all the "#define" blocks for each DECLARE_STACK_OF() statement, along with stripped down libeay.num and ssleay.num files.
2000-06-01 13:13:52 +08:00
"make update" (added to top Makefile, and applied).
1999-06-10 00:18:53 +08:00
util/libeay.num::
Use $(PERL) in place of hard-coded perl
2001-01-11 00:40:30 +08:00
$(PERL) util/mkdef.pl crypto update
"make update" (added to top Makefile, and applied).
1999-06-10 00:18:53 +08:00
util/ssleay.num::
Use $(PERL) in place of hard-coded perl
2001-01-11 00:40:30 +08:00
$(PERL) util/mkdef.pl ssl update
"make update" (added to top Makefile, and applied).
1999-06-10 00:18:53 +08:00
I got sick and tired of having to keep track of NIDs when such a thing could be done automagically, much like the numbering in libeay.num and ssleay.num. The solution works as follows: - New object identifiers are inserted in objects.txt, following the syntax given in objects.README. - objects.pl is used to process obj_mac.num and create a new obj_mac.h. - obj_dat.pl is used to create a new obj_dat.h, using the data in obj_mac.h. This is currently kind of a hack, and the perl code in objects.pl isn't very elegant, but it works as I intended. The simplest way to check that it worked correctly is to look in obj_dat.h and check the array nid_objs and make sure the objects haven't moved around (this is important!). Additions are OK, as well as consistent name changes.
2000-07-05 10:45:36 +08:00
crypto/objects/obj_dat.h: crypto/objects/obj_mac.h crypto/objects/obj_dat.pl
Use $(PERL) in place of hard-coded perl
2001-01-11 00:40:30 +08:00
$(PERL) crypto/objects/obj_dat.pl crypto/objects/obj_mac.h crypto/objects/obj_dat.h
I got sick and tired of having to keep track of NIDs when such a thing could be done automagically, much like the numbering in libeay.num and ssleay.num. The solution works as follows: - New object identifiers are inserted in objects.txt, following the syntax given in objects.README. - objects.pl is used to process obj_mac.num and create a new obj_mac.h. - obj_dat.pl is used to create a new obj_dat.h, using the data in obj_mac.h. This is currently kind of a hack, and the perl code in objects.pl isn't very elegant, but it works as I intended. The simplest way to check that it worked correctly is to look in obj_dat.h and check the array nid_objs and make sure the objects haven't moved around (this is important!). Additions are OK, as well as consistent name changes.
2000-07-05 10:45:36 +08:00
crypto/objects/obj_mac.h: crypto/objects/objects.pl crypto/objects/objects.txt
Use $(PERL) in place of hard-coded perl
2001-01-11 00:40:30 +08:00
$(PERL) crypto/objects/objects.pl crypto/objects/objects.txt crypto/objects/obj_mac.num crypto/objects/obj_mac.h
Generate obj_dat.h in "make update".
1999-09-30 05:03:02 +08:00
Oops, I forgot to add the dependency "TABLE: Configure".
1999-06-10 05:13:30 +08:00
TABLE: Configure
tiny optical change
1999-06-10 07:13:03 +08:00
(echo 'Output of `Configure TABLE'"':"; \
Use $(PERL) in place of hard-coded perl
2001-01-11 00:40:30 +08:00
$(PERL) Configure TABLE) > TABLE
"make update" (added to top Makefile, and applied).
1999-06-10 00:18:53 +08:00
This change will cause builds (by default) to not use different STACK structures and functions for each stack type. The previous behaviour can be enabled by configuring with the "-DDEBUG_SAFESTACK" option. This will also cause "make update" (mkdef.pl in particular) to update the libeay.num and ssleay.num symbol tables with the number of extra functions DEBUG_SAFESTACK creates. The way this change works is to accompany each DECLARE_STACK_OF() macro with a set of "#define"d versions of the sk_##type##_*** functions that ensures all the existing "type-safe" stack calls are precompiled into the underlying stack calls. The presence or abscence of the DEBUG_SAFESTACK symbol controls whether this block of "#define"s or the DECLARE_STACK_OF() macro is taking effect. The block of "#define"s is in turn generated and maintained by a perl script (util/mkstack.pl) that encompasses the block with delimiting C comments. This works in a similar way to the auto-generated error codes and, like the other such maintenance utilities, is invoked by the "make update" target. A long (but mundane) commit will follow this with the results of "make update" - this will include all the "#define" blocks for each DECLARE_STACK_OF() statement, along with stripped down libeay.num and ssleay.num files.
2000-06-01 13:13:52 +08:00
update: depend errors stacks util/libeay.num util/ssleay.num crypto/objects/obj_dat.h TABLE
"make update" (added to top Makefile, and applied).
1999-06-10 00:18:53 +08:00
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
tar:
Make it possible to have differing tar versions.
2000-02-24 09:59:55 +08:00
@$(TAR) $(TARFLAGS) -cvf - \
"make update" (added to top Makefile, and applied).
1999-06-10 00:18:53 +08:00
`find * \! -path CVS/\* \! -path \*/CVS/\* \! -name CVS \! -name .cvsignore \! -name STATUS \! -name TABLE | sort` |\
Start with some more tarball rolling preparation to make sure it's not overlooed next Monday: - rmlinks is no longer existing - use openssl as the name and not rse - don't roll the STATUS file into the tarball
1999-03-08 20:17:53 +08:00
tardy --user_number=0 --user_name=openssl \
*** empty log message ***
1998-12-23 15:58:53 +08:00
--group_number=0 --group_name=openssl \
--prefix=openssl-$(VERSION) - |\
Various cleanups and fixed by Marc and Ralf to start the OpenTLS project
1998-12-22 23:04:48 +08:00
gzip --best >../$(TARFILE).gz; \
ls -l ../$(TARFILE).gz
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
e_os.h does not belong with the exported headers. Do not put it there and make all files the depend on it include it without prefixing it with openssl/. This means that all Makefiles will have $(TOP) as one of the include directories.
2001-02-22 22:45:02 +08:00
tar-snap:
@$(TAR) $(TARFLAGS) -cvf - \
`find * \! -path CVS/\* \! -path \*/CVS/\* \! -name CVS \! -name .cvsignore \! -name STATUS \! -name TABLE \! -name '*.o' \! -name '*.a' \! -name '*.so' \! -name '*.so.*' \! -name 'openssl' \! -name '*test' \! -name '.#*' | sort` |\
tardy --user_number=0 --user_name=openssl \
--group_number=0 --group_name=openssl \
--prefix=openssl-$(VERSION) - > ../$(TARFILE);\
ls -l ../$(TARFILE)
Import of old SSLeay release: SSLeay 0.9.0b
1998-12-21 18:56:39 +08:00
dist:
New Makefile variables $(RANLIB) and $(PERL).
1999-04-01 20:34:33 +08:00
$(PERL) Configure dist
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
@$(MAKE) dist_pem_h
@$(MAKE) SDIRS='${SDIRS}' clean
@$(MAKE) tar
dist_pem_h:
VMS support. Submitted by: Richard Levitte <richard@levitte.org>
1999-05-13 19:37:32 +08:00
(cd crypto/pem; $(MAKE) CC='${CC}' SDIRS='${SDIRS}' CFLAG='${CFLAG}' pem.h; $(MAKE) clean)
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
Implement MD5-based "apr1" password hash.
2000-02-12 00:25:44 +08:00
install: all install_docs
Use mkdir-p.pl more efficiently.
1999-06-08 18:18:19 +08:00
@$(PERL) $(TOP)/util/mkdir-p.pl $(INSTALL_PREFIX)$(INSTALLTOP)/bin \
$(INSTALL_PREFIX)$(INSTALLTOP)/lib \
$(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl \
$(INSTALL_PREFIX)$(OPENSSLDIR)/misc \
$(INSTALL_PREFIX)$(OPENSSLDIR)/certs \
$(INSTALL_PREFIX)$(OPENSSLDIR)/private \
Implement MD5-based "apr1" password hash.
2000-02-12 00:25:44 +08:00
$(INSTALL_PREFIX)$(OPENSSLDIR)/lib
e_os* corrections.
1999-05-15 21:24:16 +08:00
@for i in $(EXHEADER) ;\
do \
(cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i; \
chmod 644 $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i ); \
done;
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
@for i in $(DIRS) ;\
do \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
if [ -d "$$i" ]; then \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
(cd $$i; echo "installing $$i..."; \
$(MAKE) CC='${CC}' CFLAG='${CFLAG}' INSTALL_PREFIX='${INSTALL_PREFIX}' INSTALLTOP='${INSTALLTOP}' OPENSSLDIR='${OPENSSLDIR}' EX_LIBS='${EX_LIBS}' SDIRS='${SDIRS}' RANLIB='${RANLIB}' install ); \
fi; \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done
@for i in $(LIBS) ;\
do \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
if [ -f "$$i" ]; then \
( echo installing $$i; \
cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
$(RANLIB) $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i; \
Redo and enhance the support for building shared libraries. Currently there's support for building under Linux and True64 (using examples from the programming manuals), including versioning that is currently the same as OpenSSL versions but should really be a different series. With this change, it's up to the users to decide if they want shared libraries as well as the static ones. This decision now has to be done at configuration time (well, not really, those who know what they do can still do it the same way as before). The OpenSSL programs (openssl and the test programs) are currently always linked statically, but this may change in the future in a configurable manner. The necessary makefile variables to enable this are in place. Also note that I have done absolutely nothing about the Windows target to get something similar. On the other hand, DLLs are already the default there, but without versioning, and I've no idea what the possibilities for such a thing are there...
2000-07-21 23:08:53 +08:00
chmod 644 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i ); \
fi \
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
done
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
@if [ -n "$(SHARED_LIBS)" ]; then \
tmp="$(SHARED_LIBS)"; \
for i in $${tmp:-x}; \
do \
if [ -f "$$i" ]; then \
( echo installing $$i; \
Some platforms (namely HP-UX) require the 'x' bit set for shared libraries. For performance reasons, it is also recommended to make the (mmap'ed) shared library 'read-only'. -> New permissions for installed shared libraries = 555 This doesn't hurt anybody, provided the installation is performed with 'cp -f' :-)
2000-11-14 19:05:10 +08:00
cp -f $$i $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \
chmod 555 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/$$i ); \
Rework the system to generate shared libraries: - Make note of the expected extension for the shared libraries and if there is a need for symbolic links from for example libcrypto.so.0 to libcrypto.so.0.9.7. There is extended info in Configure for that. - Make as few rebuilds of the shared libraries as possible. - Still avoid linking the OpenSSL programs with the shared libraries. - When installing, install the shared libraries separately from the static ones.
2000-10-13 23:25:06 +08:00
fi \
done; \
( here="`pwd`"; \
cd $(INSTALL_PREFIX)$(INSTALLTOP)/lib; \
make -f $$here/Makefile link-shared ); \
fi
Implement MD5-based "apr1" password hash.
2000-02-12 00:25:44 +08:00
install_docs:
@$(PERL) $(TOP)/util/mkdir-p.pl \
Install manpages below OPENSSLDIR (I think it was meant to be this way?). New variable for man directory.
2000-02-16 02:34:46 +08:00
$(INSTALL_PREFIX)$(MANDIR)/man1 \
$(INSTALL_PREFIX)$(MANDIR)/man3 \
$(INSTALL_PREFIX)$(MANDIR)/man5 \
$(INSTALL_PREFIX)$(MANDIR)/man7
Add a couple of forgotten $(PERL), and make the code to run pod2html a tad more readable.
2000-02-15 00:55:23 +08:00
@for i in doc/apps/*.pod; do \
fn=`basename $$i .pod`; \
sec=`[ "$$fn" = "config" ] && echo 5 || echo 1`; \
Verbose output when installing manual pages so that you see that something is going on (and what).
2000-09-26 20:23:55 +08:00
echo "installing man$$sec/`basename $$i .pod`.$$sec"; \
Manual page installation did not work if INSTALL_PREFIX was a relative path.
2000-03-09 23:04:27 +08:00
(cd `dirname $$i`; \
Add a couple of forgotten $(PERL), and make the code to run pod2html a tad more readable.
2000-02-15 00:55:23 +08:00
$(PERL) ../../util/pod2man.pl --section=$$sec --center=OpenSSL \
Manual page installation did not work if INSTALL_PREFIX was a relative path.
2000-03-09 23:04:27 +08:00
--release=$(VERSION) `basename $$i`) \
> $(INSTALL_PREFIX)$(MANDIR)/man$$sec/`basename $$i .pod`.$$sec; \
Add a couple of forgotten $(PERL), and make the code to run pod2html a tad more readable.
2000-02-15 00:55:23 +08:00
done
@for i in doc/crypto/*.pod doc/ssl/*.pod; do \
fn=`basename $$i .pod`; \
sec=`[ "$$fn" = "des_modes" ] && echo 7 || echo 3`; \
Verbose output when installing manual pages so that you see that something is going on (and what).
2000-09-26 20:23:55 +08:00
echo "installing man$$sec/`basename $$i .pod`.$$sec"; \
Manual page installation did not work if INSTALL_PREFIX was a relative path.
2000-03-09 23:04:27 +08:00
(cd `dirname $$i`; \
Add a couple of forgotten $(PERL), and make the code to run pod2html a tad more readable.
2000-02-15 00:55:23 +08:00
$(PERL) ../../util/pod2man.pl --section=$$sec --center=OpenSSL \
Manual page installation did not work if INSTALL_PREFIX was a relative path.
2000-03-09 23:04:27 +08:00
--release=$(VERSION) `basename $$i`) \
> $(INSTALL_PREFIX)$(MANDIR)/man$$sec/`basename $$i .pod`.$$sec; \
Add a couple of forgotten $(PERL), and make the code to run pod2html a tad more readable.
2000-02-15 00:55:23 +08:00
done
Import of old SSLeay release: SSLeay 0.8.1b
1998-12-21 18:52:47 +08:00
# DO NOT DELETE THIS LINE -- make depend depends on it.
Reference in New Issue Copy Permalink