On 16/09/2019 16:09, Peter Sui wrote: > Hi Matt, > 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 ? Right. > If yes, then in my application , if I have "OPENSSL_USE_DEPRECATED" > defined, the depecated functions in my application should still work, right? You don't need OPENSSL_USE_DEPRECATED at all. All of that code was removed when we changed our mind. It doesn't exist at all in the codebase today. > But it does not work. What exactly does not work? What function are you trying to call? Matt > And as I imagine, in the openssl header files(after a > successful build), it should have some "#if defines OPENSSL_USE_DEPRECATED" like > statement, but I don't see it anywhere, can you tell me how it works? > > Thanks! > > Peter > > On Mon, Sep 16, 2019 at 10:52 AM Matt Caswell <matt@xxxxxxxxxxx > <mailto:matt@xxxxxxxxxxx>> 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 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 >
