Changes between 0.9.6b and 0.9.6c [XX xxx XXXX]
+ *) Rework the configuration and shared library support for Tru64 Unix.
+ The configuration part makes use of modern compiler features and
+ still retains old compiler behavior for those that run older versions
+ of the OS. The shared library support part includes a variant that
+ uses the RPATH feature, and is available through the speciel
+ configuration target "alpha-cc-rpath", which will never be selected
+ automatically.
+ [Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu> via Richard Levitte]
+
*) In ssl3_get_key_exchange (ssl/s3_clnt.c), call ssl3_get_message()
with the same message size as in ssl3_get_certificate_request().
Otherwise, if no ServerKeyExchange message occurs, CertificateRequest
default is static libraries only, and the OpenSSL programs
are always statically linked for now, but there are
preparations for dynamic linking in place.
- This has been tested on Linux and True64.
+ This has been tested on Linux and Tru64.
[Richard Levitte]
*) Randomness polling function for Win9x, as described in:
#### HP MPE/iX http://jazz.external.hp.com/src/openssl/
"MPE/iX-gcc", "gcc:-D_ENDIAN -DBN_DIV2W -O3 -DMPE -D_POSIX_SOURCE -D_SOCKET_SOURCE -I/SYSLOG/PUB::(unknown):-L/SYSLOG/PUB -lsyslog -lsocket -lcurses:BN_LLONG DES_PTR DES_UNROLL DES_RISC1:::",
-# Dec Alpha, OSF/1 - the alpha164-cc is the flags for a 21164A with
-# the new compiler
+# Dec Alpha, OSF/1 - the alpha164-cc is historical, for the conversion
+# from the older DEC C Compiler to the newer compiler. It's now the
+# same as the preferred entry, alpha-cc. If you are still using the
+# older compiler (you're at 3.x or earlier, or perhaps very early 4.x)
+# you should use `alphaold-cc'.
+#
+# "What's in a name? That which we call a rose
+# By any other word would smell as sweet."
+#
+# - William Shakespeare, "Romeo & Juliet", Act II, scene II.
+#
+# For OSF/1 3.2b and earlier, and Digital UNIX 3.2c - 3.2g, with the
+# vendor compiler, use alphaold-cc.
+# For Digital UNIX 4.0 - 4.0e, with the vendor compiler, use alpha-cc.
+# For Tru64 UNIX 4.f - current, with the vendor compiler, use alpha-cc.
+#
+# There's also an alternate target available (which `config' will never
+# select) called alpha-cc-rpath. This target builds an RPATH into the
+# shared libraries, which is very convenient on Tru64 since binaries
+# linked against that shared library will automatically inherit that RPATH,
+# and hence know where to look for the openssl libraries, even if they're in
+# an odd place.
+#
# For gcc, the following gave a %50 speedup on a 164 over the 'DES_INT' version
-"alpha-gcc","gcc:-O3::(unknown)::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL DES_RISC1:${alpha_asm}:dlfcn:tru64-shared::.so",
-"alpha-cc", "cc:-std1 -tune host -O4 -readonly_strings::(unknown)::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:tru64-shared::.so",
-"alpha164-cc", "cc:-std1 -tune host -fast -readonly_strings::(unknown)::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:tru64-shared::.so",
+#
+"alpha-gcc","gcc:-O3::(unknown)::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL DES_RISC1:${alpha_asm}:dlfcn:alpha-osf1-shared::.so",
+"alphaold-cc", "cc:-std1 -tune host -O4 -readonly_strings::(unknown)::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:alpha-osf1-shared::.so",
+"alpha164-cc", "cc:-std1 -tune host -fast -readonly_strings::-pthread::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:tru64-shared::.so",
+"alpha-cc", "cc:-std1 -tune host -fast -readonly_strings::-pthread::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:tru64-shared::.so",
+"alpha-cc-rpath", "cc:-std1 -tune host -fast -readonly_strings::-pthread::SIXTY_FOUR_BIT_LONG RC4_CHUNK:${alpha_asm}:dlfcn:tru64-shared-rpath::.so",
+#
+# This probably belongs in a different section.
+#
"FreeBSD-alpha","gcc:-DTERMIOS -O -fomit-frame-pointer::(unknown)::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_PTR DES_RISC2::::::::::dlfcn:bsd-gcc-shared:-fPIC:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
#### Alpha Linux with GNU C and Compaq C setups
* Why does the linker complain about undefined symbols?
* Why does the OpenSSL test fail with "bc: command not found"?
* Why does the OpenSSL test fail with "bc: 1 no implemented"?
-* Why does the OpenSSL compilation fail on Alpha True64 Unix?
+* Why does the OpenSSL compilation fail on Alpha Tru64 Unix?
* Why does the OpenSSL compilation fail with "ar: command not found"?
* Why does the OpenSSL compilation fail on Win32 with VC++?
for download instructions) can be safely used, for example.
-* Why does the OpenSSL compilation fail on Alpha True64 Unix?
+* Why does the OpenSSL compilation fail on Alpha Tru64 Unix?
-On some Alpha installations running True64 Unix and Compaq C, the compilation
+On some Alpha installations running Tru64 Unix and Compaq C, the compilation
of crypto/sha/sha_dgst.c fails with the message 'Fatal: Insufficient virtual
memory to continue compilation.' As far as the tests have shown, this may be
a compiler bug. What happens is that it eats up a lot of resident memory
done
# This assumes that GNU utilities are *not* used
-do_tru64-shared:
+do_alpha-osf1-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( set -x; ${CC} -shared -no_archive -o lib$$i.so \
-set_version "${SHLIB_VERSION_HISTORY}${SHLIB_VERSION_NUMBER}" \
libs="$$libs -l$$i"; \
done
+# 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:
+ libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
+ ( set -x; ${CC} -shared -msym -no_archive -o lib$$i.so \
+ -set_version "${SHLIB_VERSION_HISTORY}${SHLIB_VERSION_NUMBER}" \
+ -all lib$$i.a -none $$libs ${EX_LIBS} -lc ) || exit 1; \
+ libs="$$libs -l$$i"; \
+ done
+
+# 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:
+ libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
+ ( set -x; ${CC} -shared -msym -no_archive -o lib$$i.so \
+ -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
+
+
# This assumes that GNU utilities are *not* used
do_solaris-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
;;
OSF1:*:*:*alpha*)
- echo "${MACHINE}-dec-osf"; exit 0
+ OSFMAJOR=`echo ${RELEASE}| sed -e 's/^V\([0-9]*\)\..*$/\1/'`
+ case "$OSFMAJOR" in
+ 4|5)
+ echo "${MACHINE}-dec-tru64"; exit 0
+ ;;
+ 1|2|3)
+ echo "${MACHINE}-dec-osf"; exit 0
+ ;;
+ *)
+ echo "${MACHINE}-dec-osf"; exit 0
+ ;;
+ esac
;;
QNX:*)
pmax*-*-openbsd) OUT="OpenBSD-mips" ;;
*-*-openbsd) OUT="OpenBSD" ;;
*86*-*-bsdi4) OUT="bsdi-elf-gcc" ;;
- *-*-osf) OUT="alpha-cc" ;;
+ *-*-osf) OUT="alphaold-cc" ;;
+ *-*-tru64) OUT="alpha-cc" ;;
*-*-unixware7) OUT="unixware-7" ;;
*-*-UnixWare7) OUT="unixware-7" ;;
*-*-Unixware7) OUT="unixware-7" ;;
*
* libcrypto.so.0
*
- * On True64 it works a little bit differently. There, the shared library
- * version is stored in the file, and is actually a series of versions,
- * separated by colons. The rightmost version present in the library when
- * linking an application is stored in the application to be matched at
- * run time. When the application is run, a check is done to see if the
- * library version stored in the application matches any of the versions
- * in the version string of the library itself.
+ * On Tru64 and IRIX 6.x it works a little bit differently. There, the
+ * shared library version is stored in the file, and is actually a series
+ * of versions, separated by colons. The rightmost version present in the
+ * library when linking an application is stored in the application to be
+ * matched at run time. When the application is run, a check is done to
+ * see if the library version stored in the application matches any of the
+ * versions in the version string of the library itself.
* This version string can be constructed in any way, depending on what
* kind of matching is desired. However, to implement the same scheme as
* the one used in the other unixen, all compatible versions, from lowest
* However, it's nice and more understandable if it actually does.
* The current library version is stored in the macro SHLIB_VERSION_NUMBER,
* which is just a piece of text in the format "M.m.e" (Major, minor, edit).
- * For the sake of True64 and any other OS that behaves in similar ways,
+ * For the sake of Tru64, IRIX, and any other OS that behaves in similar ways,
* we need to keep a history of version numbers, which is done in the
* macro SHLIB_VERSION_HISTORY. The numbers are separated by colons and
* should only keep the versions that are binary compatible with the current.
projects / oweals / openssl.git / commitdiff