"Fossies" - the Fresh Open Source Software Archive

Member "openssl-1.1.1g/include/openssl/opensslv.h" (21 Apr 2020, 4102 Bytes) of package /linux/misc/openssl-1.1.1g.tar.gz:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) C and C++ source code syntax highlighting (style: standard) with prefixed line numbers and code folding option. Alternatively you can here view or download the uninterpreted source code file. For more information about "opensslv.h" see the Fossies "Dox" file reference documentation and the last Fossies "Diffs" side-by-side code changes report: 1.1.1f_vs_1.1.1g.

    1 /*
    2  * Copyright 1999-2020 The OpenSSL Project Authors. All Rights Reserved.
    3  *
    4  * Licensed under the OpenSSL license (the "License").  You may not use
    5  * this file except in compliance with the License.  You can obtain a copy
    6  * in the file LICENSE in the source distribution or at
    7  * https://www.openssl.org/source/license.html
    8  */
    9 
   10 #ifndef HEADER_OPENSSLV_H
   11 # define HEADER_OPENSSLV_H
   12 
   13 #ifdef  __cplusplus
   14 extern "C" {
   15 #endif
   16 
   17 /*-
   18  * Numeric release version identifier:
   19  * MNNFFPPS: major minor fix patch status
   20  * The status nibble has one of the values 0 for development, 1 to e for betas
   21  * 1 to 14, and f for release.  The patch level is exactly that.
   22  * For example:
   23  * 0.9.3-dev      0x00903000
   24  * 0.9.3-beta1    0x00903001
   25  * 0.9.3-beta2-dev 0x00903002
   26  * 0.9.3-beta2    0x00903002 (same as ...beta2-dev)
   27  * 0.9.3          0x0090300f
   28  * 0.9.3a         0x0090301f
   29  * 0.9.4          0x0090400f
   30  * 1.2.3z         0x102031af
   31  *
   32  * For continuity reasons (because 0.9.5 is already out, and is coded
   33  * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level
   34  * part is slightly different, by setting the highest bit.  This means
   35  * that 0.9.5a looks like this: 0x0090581f.  At 0.9.6, we can start
   36  * with 0x0090600S...
   37  *
   38  * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.)
   39  * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for
   40  *  major minor fix final patch/beta)
   41  */
   42 # define OPENSSL_VERSION_NUMBER  0x1010107fL
   43 # define OPENSSL_VERSION_TEXT    "OpenSSL 1.1.1g  21 Apr 2020"
   44 
   45 /*-
   46  * The macros below are to be used for shared library (.so, .dll, ...)
   47  * versioning.  That kind of versioning works a bit differently between
   48  * operating systems.  The most usual scheme is to set a major and a minor
   49  * number, and have the runtime loader check that the major number is equal
   50  * to what it was at application link time, while the minor number has to
   51  * be greater or equal to what it was at application link time.  With this
   52  * scheme, the version number is usually part of the file name, like this:
   53  *
   54  *      libcrypto.so.0.9
   55  *
   56  * Some unixen also make a softlink with the major version number only:
   57  *
   58  *      libcrypto.so.0
   59  *
   60  * On Tru64 and IRIX 6.x it works a little bit differently.  There, the
   61  * shared library version is stored in the file, and is actually a series
   62  * of versions, separated by colons.  The rightmost version present in the
   63  * library when linking an application is stored in the application to be
   64  * matched at run time.  When the application is run, a check is done to
   65  * see if the library version stored in the application matches any of the
   66  * versions in the version string of the library itself.
   67  * This version string can be constructed in any way, depending on what
   68  * kind of matching is desired.  However, to implement the same scheme as
   69  * the one used in the other unixen, all compatible versions, from lowest
   70  * to highest, should be part of the string.  Consecutive builds would
   71  * give the following versions strings:
   72  *
   73  *      3.0
   74  *      3.0:3.1
   75  *      3.0:3.1:3.2
   76  *      4.0
   77  *      4.0:4.1
   78  *
   79  * Notice how version 4 is completely incompatible with version, and
   80  * therefore give the breach you can see.
   81  *
   82  * There may be other schemes as well that I haven't yet discovered.
   83  *
   84  * So, here's the way it works here: first of all, the library version
   85  * number doesn't need at all to match the overall OpenSSL version.
   86  * However, it's nice and more understandable if it actually does.
   87  * The current library version is stored in the macro SHLIB_VERSION_NUMBER,
   88  * which is just a piece of text in the format "M.m.e" (Major, minor, edit).
   89  * For the sake of Tru64, IRIX, and any other OS that behaves in similar ways,
   90  * we need to keep a history of version numbers, which is done in the
   91  * macro SHLIB_VERSION_HISTORY.  The numbers are separated by colons and
   92  * should only keep the versions that are binary compatible with the current.
   93  */
   94 # define SHLIB_VERSION_HISTORY ""
   95 # define SHLIB_VERSION_NUMBER "1.1"
   96 
   97 
   98 #ifdef  __cplusplus
   99 }
  100 #endif
  101 #endif                          /* HEADER_OPENSSLV_H */