mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-27 05:21:51 +08:00
Code Issues Packages Projects Releases Wiki Activity
f924200e1b
openssl/Makefile.org

728 lines
24 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=
We really have no need for PEX_LIBS, so empty it.
2001-03-23 05:20:54 +08:00
PEX_LIBS=
Various cleanups and fixed by Marc and Ralf to start the OpenTLS project
1998-12-22 23:04:48 +08:00
EX_LIBS=
Incorporate some changes that make OpenSSL compilable in CygWin.
2001-04-04 23:50:30 +08:00
EXE_EXT=
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 \
Because Rijndael is more known as AES, use crypto/aes instead of crypto/rijndael. Additionally, I applied the AES integration patch from Stephen Sprunk <stephen@sprunk.org> and fiddled it to work properly with the normal EVP constructs (and incidently work the same way as all other symmetric cipher implementations). This results in an API that looks a lot like the rest of the OpenSSL cipher suite.
2002-01-03 00:55:35 +08:00
bn ec rsa dsa dh dso engine aes \
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 \
Patches from Vern Staats <staatsvr@asc.hpc.mil> to get Kerberos 5 in SSL according to RFC 2712. His comment is: This is a patch to openssl-SNAP-20010702 to support Kerberized SSL authentication. I'm expecting to have the full kssl-0.5 kit up on sourceforge by the end of the week. The full kit includes patches for mod-ssl, apache, and a few text clients. The sourceforge URL is http://sourceforge.net/projects/kssl/ . Thanks to a note from Simon Wilkinson I've replaced my KRB5 AP_REQ message with a real KerberosWrapper struct. I think this is fully RFC 2712 compliant now, including support for the optional authenticator field. I also added openssl-style ASN.1 macros for a few Kerberos structs; see crypto/krb5/ if you're interested.
2001-07-10 05:46:58 +08:00
evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp ocsp ui krb5
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=
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
SHARED_LDFLAGS=
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
Change the shared library support so the shared libraries get built sooner and the programs get built against the shared libraries. This requires a bit more work. Things like -rpath and the possibility to still link the programs statically should be included. Some cleanup is also needed. This will be worked on.
2001-10-30 16:00:59 +08:00
all: 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..." && \
Make SHLIB_TARGET available in subdirs (here: apps/)
2002-01-30 00:20:08 +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}' EXE_EXT='${EXE_EXT}' SHARED_LIBS='${SHARED_LIBS}' SHLIB_EXT='${SHLIB_EXT}' SHLIB_TARGET='${SHLIB_TARGET}' 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; \
Superflous '\' messes up with HP-UX make.
2002-01-29 00:30:06 +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
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
Superflous '\' messes up with HP-UX make.
2002-01-29 00:30:06 +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
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 \
Minimise the amount of -L. when linking the shared libraries. It seems like some Unixen (SCO) have opinions about too many -L.
2001-03-16 06:10:07 +08:00
$(MAKE) SHLIBDIRS=ssl SHLIBDEPS='-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 \
ln on Solaris expects -f to come before -s. The linux-shared method is actually gcc-specific, so call it gnu-shared as well.
2001-03-24 19:45:57 +08:00
( set -x; ln -f -s $$prev lib$$i$$j ); \
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
prev=lib$$i$$j; \
done; \
fi; \
done
build-shared: clean-shared do_$(SHLIB_TARGET) link-shared
Make do_bsd-gcc-shared depend on do_gnu-shared instead of the non-existent linux-shared
2001-04-04 12:24:24 +08:00
do_bsd-gcc-shared: do_gnu-shared
ln on Solaris expects -f to come before -s. The linux-shared method is actually gcc-specific, so call it gnu-shared as well.
2001-03-24 19:45:57 +08:00
do_linux-shared: do_gnu-shared
do_gnu-shared:
Minimise the amount of -L. when linking the shared libraries. It seems like some Unixen (SCO) have opinions about too many -L.
2001-03-16 06:10:07 +08:00
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
( set -x; ${CC} ${SHARED_LDFLAGS} \
-shared -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
Linux shared libraries can be linked with debug symbols. Tru64 shared libraries can be linked with static libraries.
2001-04-27 04:17:59 +08:00
-Wl,-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; \
Minimise the amount of -L. when linking the shared libraries. It seems like some Unixen (SCO) have opinions about too many -L.
2001-03-16 06:10:07 +08:00
libs="$$libs -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
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
DETECT_GNU_LD=${CC} -v 2>&1 | grep '^gcc' >/dev/null 2>&1 && \
collect2=`gcc -print-prog-name=collect2 2>&1` && \
[ -n "$$collect2" ] && \
my_ld=`$$collect2 --help 2>&1 | grep Usage: | sed 's/^Usage: *\([^ ][^ ]*\).*/\1/'` && \
[ -n "$$my_ld" ] && \
$$my_ld -v 2>&1 | grep 'GNU ld' >/dev/null 2>&1
Patches to make OpenSSL compilable on MacOS/X. Submitted by Pier Fumagalli <pier@betaversion.org>
2002-01-08 17:19:31 +08:00
# For Darwin AKA Mac OS/X (dyld)
do_darwin-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( set -x ; ${CC} --verbose -dynamiclib -o lib$$i${SHLIB_EXT} \
lib$$i.a $$libs -all_load -current_version ${SHLIB_MAJOR}.${SHLIB_MINOR} \
-compatibility_version ${SHLIB_MAJOR}.`echo ${SHLIB_MINOR} | cut -d. -f1` \
-install_name ${INSTALLTOP}/lib/lib$$i${SHLIB_EXT} ) || exit 1; \
libs="$$libs -l`basename $$i${SHLIB_EXT} .dylib`"; \
echo "" ; \
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
Apply the Tru64 patch from Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu> His comments are: 1) Changes all references for `True64' to be `Tru64', which is the correct spelling for the OS name. 2) Makes `alpha-cc' be the same as `alpha164-cc', and adds an `alphaold-cc' entry that is the same as the previous `alpha-cc'. The reason is that most people these days are using the newer compiler, so it should be the default. 3) Adds a bit of commentary to Configure, regarding the name changes of the OS over the years, so it's not so confusing to people that haven't been with the OS for a while. 4) Adds an `alpha-cc-rpath' target (which is *not* selected automatically by Configure under any circumstance) that builds an RPATH into the shared libraries. This is explained in the comment in Configure. It's very very useful for people that want it, and people that don't want it just shouldn't choose that target. 5) Adds the `-pthread' flag as the best way to get POSIX thread support from the newer compiler. 6) Updates the Makefile targets, so that when the `alpha164-cc', `alpha-cc', or `alpha-cc-rpath' target is what Configure is set to use, it uses a Makefile target that includes the `-msym' option when building the shared library. This is a performance enhancement. 7) Updates `config' so that if it detects you're running version 4 or 5 of the OS, it automatically selects `alpha-cc', but uses `alphaold-cc' for versions 1-3 of the OS. 8) Updates the comment in opensslv.h, fixing both the OS name typo and adding a reference to IRIX 6.x, since the shared library semantics are virtually identical there.
2001-08-10 23:26:21 +08:00
do_alpha-osf1-shared:
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
if ${DETECT_GNU_LD}; then \
$(MAKE) do_gnu-shared; \
else \
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
( set -x; ${CC} ${SHARED_LDFLAGS} \
-shared -o lib$$i.so \
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
-set_version "${SHLIB_VERSION_HISTORY}${SHLIB_VERSION_NUMBER}" \
-all lib$$i.a -none $$libs ${EX_LIBS} -lc ) || exit 1; \
libs="$$libs -l$$i"; \
done; \
fi
Linux shared libraries.
1999-04-29 00:16:31 +08:00
Apply the Tru64 patch from Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu> His comments are: 1) Changes all references for `True64' to be `Tru64', which is the correct spelling for the OS name. 2) Makes `alpha-cc' be the same as `alpha164-cc', and adds an `alphaold-cc' entry that is the same as the previous `alpha-cc'. The reason is that most people these days are using the newer compiler, so it should be the default. 3) Adds a bit of commentary to Configure, regarding the name changes of the OS over the years, so it's not so confusing to people that haven't been with the OS for a while. 4) Adds an `alpha-cc-rpath' target (which is *not* selected automatically by Configure under any circumstance) that builds an RPATH into the shared libraries. This is explained in the comment in Configure. It's very very useful for people that want it, and people that don't want it just shouldn't choose that target. 5) Adds the `-pthread' flag as the best way to get POSIX thread support from the newer compiler. 6) Updates the Makefile targets, so that when the `alpha164-cc', `alpha-cc', or `alpha-cc-rpath' target is what Configure is set to use, it uses a Makefile target that includes the `-msym' option when building the shared library. This is a performance enhancement. 7) Updates `config' so that if it detects you're running version 4 or 5 of the OS, it automatically selects `alpha-cc', but uses `alphaold-cc' for versions 1-3 of the OS. 8) Updates the comment in opensslv.h, fixing both the OS name typo and adding a reference to IRIX 6.x, since the shared library semantics are virtually identical there.
2001-08-10 23:26:21 +08:00
# This assumes that GNU utilities are *not* used
# The difference between alpha-osf1-shared and tru64-shared is the `-msym'
# option passed to the linker.
do_tru64-shared:
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
if ${DETECT_GNU_LD}; then \
$(MAKE) do_gnu-shared; \
else \
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
( set -x; ${CC} ${SHARED_LDFLAGS} \
-shared -msym -o lib$$i.so \
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
-set_version "${SHLIB_VERSION_HISTORY}${SHLIB_VERSION_NUMBER}" \
-all lib$$i.a -none $$libs ${EX_LIBS} -lc ) || exit 1; \
libs="$$libs -l$$i"; \
done; \
fi
Apply the Tru64 patch from Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu> His comments are: 1) Changes all references for `True64' to be `Tru64', which is the correct spelling for the OS name. 2) Makes `alpha-cc' be the same as `alpha164-cc', and adds an `alphaold-cc' entry that is the same as the previous `alpha-cc'. The reason is that most people these days are using the newer compiler, so it should be the default. 3) Adds a bit of commentary to Configure, regarding the name changes of the OS over the years, so it's not so confusing to people that haven't been with the OS for a while. 4) Adds an `alpha-cc-rpath' target (which is *not* selected automatically by Configure under any circumstance) that builds an RPATH into the shared libraries. This is explained in the comment in Configure. It's very very useful for people that want it, and people that don't want it just shouldn't choose that target. 5) Adds the `-pthread' flag as the best way to get POSIX thread support from the newer compiler. 6) Updates the Makefile targets, so that when the `alpha164-cc', `alpha-cc', or `alpha-cc-rpath' target is what Configure is set to use, it uses a Makefile target that includes the `-msym' option when building the shared library. This is a performance enhancement. 7) Updates `config' so that if it detects you're running version 4 or 5 of the OS, it automatically selects `alpha-cc', but uses `alphaold-cc' for versions 1-3 of the OS. 8) Updates the comment in opensslv.h, fixing both the OS name typo and adding a reference to IRIX 6.x, since the shared library semantics are virtually identical there.
2001-08-10 23:26:21 +08:00
# This assumes that GNU utilities are *not* used
# The difference between tru64-shared and tru64-shared-rpath is the
# -rpath ${INSTALLTOP}/lib passed to the linker.
do_tru64-shared-rpath:
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
if ${DETECT_GNU_LD}; then \
$(MAKE) do_gnu-shared; \
else \
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
( set -x; ${CC} ${SHARED_LDFLAGS} \
-shared -msym -o lib$$i.so \
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
-rpath ${INSTALLTOP}/lib \
-set_version "${SHLIB_VERSION_HISTORY}${SHLIB_VERSION_NUMBER}" \
-all lib$$i.a -none $$libs ${EX_LIBS} -lc ) || exit 1; \
libs="$$libs -l$$i"; \
done; \
fi
Apply the Tru64 patch from Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu> His comments are: 1) Changes all references for `True64' to be `Tru64', which is the correct spelling for the OS name. 2) Makes `alpha-cc' be the same as `alpha164-cc', and adds an `alphaold-cc' entry that is the same as the previous `alpha-cc'. The reason is that most people these days are using the newer compiler, so it should be the default. 3) Adds a bit of commentary to Configure, regarding the name changes of the OS over the years, so it's not so confusing to people that haven't been with the OS for a while. 4) Adds an `alpha-cc-rpath' target (which is *not* selected automatically by Configure under any circumstance) that builds an RPATH into the shared libraries. This is explained in the comment in Configure. It's very very useful for people that want it, and people that don't want it just shouldn't choose that target. 5) Adds the `-pthread' flag as the best way to get POSIX thread support from the newer compiler. 6) Updates the Makefile targets, so that when the `alpha164-cc', `alpha-cc', or `alpha-cc-rpath' target is what Configure is set to use, it uses a Makefile target that includes the `-msym' option when building the shared library. This is a performance enhancement. 7) Updates `config' so that if it detects you're running version 4 or 5 of the OS, it automatically selects `alpha-cc', but uses `alphaold-cc' for versions 1-3 of the OS. 8) Updates the comment in opensslv.h, fixing both the OS name typo and adding a reference to IRIX 6.x, since the shared library semantics are virtually identical there.
2001-08-10 23:26:21 +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:
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
if ${DETECT_GNU_LD}; then \
$(MAKE) do_gnu-shared; \
else \
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( PATH=/usr/ccs/bin:$$PATH ; export PATH; \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
set -x; ${CC} ${SHARED_LDFLAGS} \
-G -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
-h lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-z allextract lib$$i.a $$libs ${EX_LIBS} -lc ) || exit 1; \
Update SCO5 targets.
2002-01-26 13:24:05 +08:00
libs="$$libs -l$$i"; \
done; \
fi
# OpenServer 5 native compilers used
do_svr3-shared:
if ${DETECT_GNU_LD}; then \
$(MAKE) do_gnu-shared; \
else \
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( PATH=/usr/ccs/bin:$$PATH ; export PATH; \
find . -name "*.o" -print > allobjs ; \
OBJS= ; export OBJS ; \
for obj in `ar t lib$$i.a` ; do \
OBJS="$${OBJS} `grep $$obj allobjs`" ; \
done ; \
set -x; ${CC} -G -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-h lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
$${OBJS} $$libs ${EX_LIBS} ) || exit 1; \
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
libs="$$libs -l$$i"; \
done; \
fi
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
Support for shared libraries on Unixware-7 and OpenUNIX-8 (Boyd Lynn Gerber <gerberb@zenez.com>).
2001-09-06 20:39:00 +08:00
# UnixWare 7 and OpenUNIX 8 native compilers used
do_svr5-shared:
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
if ${DETECT_GNU_LD}; then \
$(MAKE) do_gnu-shared; \
else \
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( PATH=/usr/ccs/bin:$$PATH ; export PATH; \
find . -name "*.o" -print > allobjs ; \
OBJS= ; export OBJS ; \
for obj in `ar t lib$$i.a` ; do \
OBJS="$${OBJS} `grep $$obj allobjs`" ; \
done ; \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
set -x; ${CC} ${SHARED_LDFLAGS} \
-G -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
-h lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
$${OBJS} $$libs ${EX_LIBS} ) || exit 1; \
libs="$$libs -l$$i"; \
done; \
fi
Support for shared libraries on Unixware-7 and OpenUNIX-8 (Boyd Lynn Gerber <gerberb@zenez.com>).
2001-09-06 20:39:00 +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:
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
if ${DETECT_GNU_LD}; then \
$(MAKE) do_gnu-shared; \
else \
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
( set -x; ${CC} ${SHARED_LDFLAGS} \
-shared -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
For systems where gcc is used and where we don't know if GNU ld is used or not, let's ask collect2 which ld it uses and choose to use the target do-gnu_shared if GNU ld is used. This solves the reported problems on Solaris systems where GNU cc is used but GNU ld isn't, and probably on other systems with similar setups.
2001-10-10 22:46:41 +08:00
-Wl,-soname,lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-all lib$$i.a $$libs ${EX_LIBS} -lc) || exit 1; \
libs="$$libs -l$$i"; \
done; \
fi
Add support for shared libraries under Irix. Submitted by Albert Chin-A-Young <china@thewrittenword.com>
2000-11-01 08:05:04 +08:00
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 \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
( set -x; /usr/ccs/bin/ld ${SHARED_LDFLAGS} \
+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 \
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
( set -x; /usr/ccs/bin/ld ${SHARED_LDFLAGS} \
-b -z \
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
-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
A method to create shared libraries on AIX, and according to "Howard Chu" <hyc@highlandsun.com>, it may be general enough to work on any Unixly system.
2001-04-28 05:33:44 +08:00
# The following method is said to work on all platforms. Tests will
# determine if that's how it's gong to be used.
# This assumes that for all but GNU systems, GNU utilities are *not* used.
# ALLSYMSFLAGS would be:
# GNU systems: --whole-archive
# Tru64 Unix: -all
# Solaris: -z allextract
# Irix: -all
# HP/UX-32bit: -Fl
# HP/UX-64bit: +forceload
# AIX: -bnogc
# SHAREDFLAGS would be:
# GNU systems: -shared -Wl,-soname=lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR}
# Tru64 Unix: -shared \
# -set_version "${SHLIB_VERSION_HISTORY}${SHLIB_VERSION_NUMBER}"
# Solaris: -G -h lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR}
# Irix: -shared -Wl,-soname,lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR}
# HP/UX-32bit: +vnocompatwarnings -b -z +s \
# +h lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR}
# HP/UX-64bit: -b -z +h lib$$i.sl.${SHLIB_MAJOR}.${SHLIB_MINOR}
Small detail about AIX forgotten...
2001-06-05 12:41:57 +08:00
# AIX: -G -bE:lib$$i.exp -bM:SRE
A method to create shared libraries on AIX, and according to "Howard Chu" <hyc@highlandsun.com>, it may be general enough to work on any Unixly system.
2001-04-28 05:33:44 +08:00
# SHAREDCMD would be:
# GNU systems: $(CC)
# Tru64 Unix: $(CC)
# Solaris: $(CC)
# Irix: $(CC)
# HP/UX-32bit: /usr/ccs/bin/ld
# HP/UX-64bit: /usr/ccs/bin/ld
# AIX: $(CC)
ALLSYMSFLAG=-bnogc
On Solaris64, cc needs the flag -xarch=v9 when linking shared libraries. Make a general change to support shared library linking flags in general. Noted by Nick Briggs <briggs@parc.xerox.com>
2002-01-02 18:30:07 +08:00
SHAREDFLAGS=${SHARED_LDFLAGS} -G -bE:lib$$i.exp -bM:SRE
A method to create shared libraries on AIX, and according to "Howard Chu" <hyc@highlandsun.com>, it may be general enough to work on any Unixly system.
2001-04-28 05:33:44 +08:00
SHAREDCMD=$(CC)
do_aix-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( set -x; \
ld -r -o $$i.o $(ALLSYMSFLAG) lib$$i.a && \
( nm -Pg lib$$i.o | grep ' [BD] ' | cut -f1 -d' ' > lib$$i.exp; \
$(SHAREDCMD) $(SHAREDFLAG) -o lib$$i.so lib$$i.o \
$$libs ${EX_LIBS} ) ) \
|| exit 1; \
libs="$$libs -l$$i"; \
done
Add old patch from Robert Dahlem <Robert.Dahlem@ffm2.siemens.de> to make it possible to produce shared libraries on ReliantUNIX.
2002-01-26 11:17:27 +08:00
do_reliantunix-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
tmpdir=/tmp/openssl.$$$$ ; rm -rf $$tmpdir ; \
( set -x; \
( Opwd=`pwd` ; mkdir $$tmpdir || exit 1; \
cd $$tmpdir || exit 1 ; ar x $$Opwd/lib$$i.a ; \
${CC} -G -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} *.o \
) || exit 1; \
cp $$tmpdir/lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} . ; \
) || exit 1; \
rm -rf $$tmpdir ; \
libs="$$libs -l$$i"; \
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
Change the shared library support so the shared libraries get built sooner and the programs get built against the shared libraries. This requires a bit more work. Things like -rpath and the possibility to still link the programs statically should be included. Some cleanup is also needed. This will be worked on.
2001-10-30 16:00:59 +08:00
@(OPENSSL="`pwd`/apps/openssl"; OPENSSL_DEBUG_MEMORY=on; \
export OPENSSL OPENSSL_DEBUG_MEMORY; \
LD_LIBRARY_PATH="`pwd`"; SHLIB_PATH="`pwd`"; LIBPATH="`pwd`"; \
export LD_LIBRARY_PATH SHLIB_PATH LIBPATH; \
$(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..." && \
Incorporate some changes that make OpenSSL compilable in CygWin.
2001-04-04 23:50:30 +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}' EXE_EXT='${EXE_EXT}' OPENSSL_DEBUG_MEMORY=on tests );
Change the shared library support so the shared libraries get built sooner and the programs get built against the shared libraries. This requires a bit more work. Things like -rpath and the possibility to still link the programs statically should be included. Some cleanup is also needed. This will be worked on.
2001-10-30 16:00:59 +08:00
@LD_LIBRARY_PATH="`pwd`"; SHLIB_PATH="`pwd`"; LIBPATH="`pwd`"; \
export LD_LIBRARY_PATH SHLIB_PATH LIBPATH; \
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..." && \
Patches from Vern Staats <staatsvr@asc.hpc.mil> to get Kerberos 5 in SSL according to RFC 2712. His comment is: This is a patch to openssl-SNAP-20010702 to support Kerberized SSL authentication. I'm expecting to have the full kssl-0.5 kit up on sourceforge by the end of the week. The full kit includes patches for mod-ssl, apache, and a few text clients. The sourceforge URL is http://sourceforge.net/projects/kssl/ . Thanks to a note from Simon Wilkinson I've replaced my KRB5 AP_REQ message with a real KerberosWrapper struct. I think this is fully RFC 2712 compliant now, including support for the optional authenticator field. I also added openssl-style ASN.1 macros for a few Kerberos structs; see crypto/krb5/ if you're interested.
2001-07-10 05:46:58 +08:00
$(MAKE) SDIRS='${SDIRS}' DEPFLAG='${DEPFLAG}' MAKEDEPPROG='${MAKEDEPPROG}' KRB5_INCLUDES='${KRB5_INCLUDES}' 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
Change obj_... generation so that it does not generate rubbish or abort with errors if no name is defined for some object, which was the case for 'pilotAttributeType 27'. Also avoid this very situation by assigning the name 'pilotAttributeType27'.
2001-03-06 16:58:38 +08:00
crypto/objects/obj_dat.h: crypto/objects/obj_dat.pl crypto/objects/obj_mac.h
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
typo
2001-03-14 00:30:09 +08:00
crypto/objects/obj_mac.h: crypto/objects/objects.pl crypto/objects/objects.txt crypto/objects/obj_mac.num
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..."; \
Incorporate some changes that make OpenSSL compilable in CygWin.
2001-04-04 23:50:30 +08:00
$(MAKE) CC='${CC}' CFLAG='${CFLAG}' INSTALL_PREFIX='${INSTALL_PREFIX}' INSTALLTOP='${INSTALLTOP}' OPENSSLDIR='${OPENSSLDIR}' EX_LIBS='${EX_LIBS}' SDIRS='${SDIRS}' RANLIB='${RANLIB}' EXE_EXT='${EXE_EXT}' install ); \
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
@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`; \
'||', '&&' and 'test -x' apparently don't work on Ultrix; also 'test' appears to be available as '[' only in 'if' conditions.
2001-04-08 21:49:45 +08:00
if [ "$$fn" = "config" ]; then sec=5; else sec=1; fi; \
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`; \
'||', '&&' and 'test -x' apparently don't work on Ultrix; also 'test' appears to be available as '[' only in 'if' conditions.
2001-04-08 21:49:45 +08:00
if [ "$$fn" = "des_modes" ]; then sec=7; else sec=3; fi; \
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