building openssl-1.1.1d with "enable-deprecated"

[Matt Caswell]

On 16/09/2019 15:44, Peter Sui wrote:
> Hi,
>        From the openssl website, I got the folloeing instruction:
> "
> Access to deprecated functions/macros has been removed by default. To enable
> access you must do two things. 1) Build OpenSSL with deprecation support (pass
> "enable-deprecated" as an argument to config) 2) Applications must define
> "OPENSSL_USE_DEPRECATED" before including OpenSSL header files.
> "
> But, after I followed the instructions, it did not work. I searched all the
> files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED"  anywhere. And
> in the make file generated, I found it's using the
> flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions
> available in the library built?  I also compared all the binary and header files
> between the build without "enable-deprecated" and the build
> with "enable-deprecated", there is no difference.
> The command I used is:
> perl Configure VC-WIN32 enable-deprecated
> --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015
> nmake
> 

That CHANGES entry is incorrect and out-of-date. It should probably be removed.
The original CHANGES entry said this:

  *) config has been changed so that by default OPENSSL_NO_DEPRECATED is used.
     Access to deprecated functions can be re-enabled by running config with
     "enable-deprecated". In addition applications wishing to use deprecated
     functions must define OPENSSL_USE_DEPRECATED. Note that this new behaviour
     will, by default, disable some transitive includes that previously existed
     in the header files (e.g. ec.h will no longer, by default, include bn.h)
     [Matt Caswell]

That CHANGES entry was added while 1.1.0 was being developed. However before
1.1.0 was released we changed our mind and added this CHANGES entry:

  *) Revert default OPENSSL_NO_DEPRECATED setting.  Instead OpenSSL
     continues to support deprecated interfaces in default builds.
     However, applications are strongly advised to compile their
     source files with -DOPENSSL_API_COMPAT=0x10100000L, which hides
     the declarations of all interfaces deprecated in 0.9.8, 1.0.0
     or the 1.1.0 releases.

     In environments in which all applications have been ported to
     not use any deprecated interfaces OpenSSL's Configure script
     should be used with the --api=1.1.0 option to entirely remove
     support for the deprecated features from the library and
     unconditionally disable them in the installed headers.
     Essentially the same effect can be achieved with the "no-deprecated"
     argument to Configure, except that this will always restrict
     the build to just the latest API, rather than a fixed API
     version.

     As applications are ported to future revisions of the API,
     they should update their compile-time OPENSSL_API_COMPAT define
     accordingly, but in most cases should be able to continue to
     compile with later releases.

     The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are
     0x10000000L and 0x00908000L, respectively.  However those
     versions did not support the OPENSSL_API_COMPAT feature, and
     so applications are not typically tested for explicit support
     of just the undeprecated features of either release.
     [Viktor Dukhovni]

Regards

Matt