building openssl-1.1.1d with "enable-deprecated"
peters at qnext.com
Mon Sep 16 15:09:44 UTC 2019
So you are saying configuring with "enable-deprecated" or not won't
make the build different, they are all actually support the deprecated
functions, right ? If yes, then in my application , if I have
defined, the depecated functions in my application should still work,
right? But it does not work. And as I imagine, in the openssl header
files(after a successful build), it should have some "#if defines
like statement, but I don't see it anywhere, can you tell me how it works?
On Mon, Sep 16, 2019 at 10:52 AM Matt Caswell <matt at openssl.org> wrote:
> 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
> > access you must do two things. 1) Build OpenSSL with deprecation support
> > "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
> > 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
> The original CHANGES entry said this:
> *) config has been changed so that by default OPENSSL_NO_DEPRECATED is
> Access to deprecated functions can be re-enabled by running config
> "enable-deprecated". In addition applications wishing to use
> functions must define OPENSSL_USE_DEPRECATED. Note that this new
> will, by default, disable some transitive includes that previously
> in the header files (e.g. ec.h will no longer, by default, include
> [Matt Caswell]
> That CHANGES entry was added while 1.1.0 was being developed. However
> 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
> 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]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users