1.1 --- a/epoc32/include/stdapis/openssl/opensslv.h	Tue Nov 24 13:55:44 2009 +0000
     1.2 +++ b/epoc32/include/stdapis/openssl/opensslv.h	Tue Mar 16 16:12:26 2010 +0000
     1.3 @@ -1,1 +1,94 @@
     1.4 -opensslv.h
     1.5 +#ifndef HEADER_OPENSSLV_H
     1.6 +#define HEADER_OPENSSLV_H
     1.7 +
     1.8 +/* Numeric release version identifier:
     1.9 + * MNNFFPPS: major minor fix patch status
    1.10 + * The status nibble has one of the values 0 for development, 1 to e for betas
    1.11 + * 1 to 14, and f for release.  The patch level is exactly that.
    1.12 + * For example:
    1.13 + * 0.9.3-dev	  0x00903000
    1.14 + * 0.9.3-beta1	  0x00903001
    1.15 + * 0.9.3-beta2-dev 0x00903002
    1.16 + * 0.9.3-beta2    0x00903002 (same as ...beta2-dev)
    1.17 + * 0.9.3	  0x0090300f
    1.18 + * 0.9.3a	  0x0090301f
    1.19 + * 0.9.4	  0x0090400f
    1.20 + * 1.2.3z	  0x102031af
    1.21 + *
    1.22 + * For continuity reasons (because 0.9.5 is already out, and is coded
    1.23 + * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
    1.24 + * part is slightly different, by setting the highest bit.  This means
    1.25 + * that 0.9.5a looks like this: 0x0090581f.  At 0.9.6, we can start
    1.26 + * with 0x0090600S...
    1.27 + *
    1.28 + * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
    1.29 + * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
    1.30 + *  major minor fix final patch/beta)
    1.31 + */
    1.32 +
    1.33 +#if (defined(__SYMBIAN32__) && !defined(SYMBIAN))
    1.34 +#define SYMBIAN
    1.35 +#endif
    1.36 +  
    1.37 +#define OPENSSL_VERSION_NUMBER	0x0090807fL
    1.38 +#ifdef OPENSSL_FIPS
    1.39 +#define OPENSSL_VERSION_TEXT	"OpenSSL 0.9.8g-fips 19 Oct 2007"
    1.40 +#else
    1.41 +#define OPENSSL_VERSION_TEXT	"OpenSSL 0.9.8g 19 Oct 2007"
    1.42 +#endif
    1.43 +#define OPENSSL_VERSION_PTEXT	" part of " OPENSSL_VERSION_TEXT
    1.44 +
    1.45 +
    1.46 +/* The macros below are to be used for shared library (.so, .dll, ...)
    1.47 + * versioning.  That kind of versioning works a bit differently between
    1.48 + * operating systems.  The most usual scheme is to set a major and a minor
    1.49 + * number, and have the runtime loader check that the major number is equal
    1.50 + * to what it was at application link time, while the minor number has to
    1.51 + * be greater or equal to what it was at application link time.  With this
    1.52 + * scheme, the version number is usually part of the file name, like this:
    1.53 + *
    1.54 + *	libcrypto.so.0.9
    1.55 + *
    1.56 + * Some unixen also make a softlink with the major verson number only:
    1.57 + *
    1.58 + *	libcrypto.so.0
    1.59 + *
    1.60 + * On Tru64 and IRIX 6.x it works a little bit differently.  There, the
    1.61 + * shared library version is stored in the file, and is actually a series
    1.62 + * of versions, separated by colons.  The rightmost version present in the
    1.63 + * library when linking an application is stored in the application to be
    1.64 + * matched at run time.  When the application is run, a check is done to
    1.65 + * see if the library version stored in the application matches any of the
    1.66 + * versions in the version string of the library itself.
    1.67 + * This version string can be constructed in any way, depending on what
    1.68 + * kind of matching is desired.  However, to implement the same scheme as
    1.69 + * the one used in the other unixen, all compatible versions, from lowest
    1.70 + * to highest, should be part of the string.  Consecutive builds would
    1.71 + * give the following versions strings:
    1.72 + *
    1.73 + *	3.0
    1.74 + *	3.0:3.1
    1.75 + *	3.0:3.1:3.2
    1.76 + *	4.0
    1.77 + *	4.0:4.1
    1.78 + *
    1.79 + * Notice how version 4 is completely incompatible with version, and
    1.80 + * therefore give the breach you can see.
    1.81 + *
    1.82 + * There may be other schemes as well that I haven't yet discovered.
    1.83 + *
    1.84 + * So, here's the way it works here: first of all, the library version
    1.85 + * number doesn't need at all to match the overall OpenSSL version.
    1.86 + * However, it's nice and more understandable if it actually does.
    1.87 + * The current library version is stored in the macro SHLIB_VERSION_NUMBER,
    1.88 + * which is just a piece of text in the format "M.m.e" (Major, minor, edit).
    1.89 + * For the sake of Tru64, IRIX, and any other OS that behaves in similar ways,
    1.90 + * we need to keep a history of version numbers, which is done in the
    1.91 + * macro SHLIB_VERSION_HISTORY.  The numbers are separated by colons and
    1.92 + * should only keep the versions that are binary compatible with the current.
    1.93 + */
    1.94 +#define SHLIB_VERSION_HISTORY ""
    1.95 +#define SHLIB_VERSION_NUMBER "0.9.8"
    1.96 +
    1.97 +
    1.98 +#endif /* HEADER_OPENSSLV_H */