my mistake -- it was in there on Apr 18 at least. i guess that's a little old
OpenSSL version 1.1.1b 26 Feb 2019 here On Thu, Apr 25, 2019 at 6:28 PM Greg A. Woods <wo...@planix.com> wrote: > > At Thu, 25 Apr 2019 17:18:09 +0200, Martin Husemann <mar...@duskware.de> > wrote: > Subject: Re: SSL_library_init not found in libssl in current > > > > On Thu, Apr 25, 2019 at 08:34:05PM +0530, Mayuresh wrote: > > > On Thu, Apr 25, 2019 at 04:57:10PM +0200, Martin Husemann wrote: > > > > Note that the issue is the openssl version, not the architecture (or > > > > am I missing something?) > > > > > > I'd think so. Just that mail from JP on this thread says the symbol is > > > present on current amd64. I personally have only evbarm current and 8.0 > > > amd64. > > > > Yeah, but it is not present in amd64 -current as of a few days ago any more > > ;-) > > More than a few days.... > > I don't have it by default in a build from a Jan 31 checkout. > > However I do still have the manual page, which ends with: > > The SSL_library_init() and OpenSSL_add_ssl_algorithms() functions were > deprecated in OpenSSL 1.1.0 by OPENSSL_init_ssl(). > > BTW, that manual page also clearly states the function should be found > in libcrypto (NOT libssl). But.... > > However, if one examines the source tree one quickly finds out that > SSL_library_init() is now a macro (in openssl/ssl.h) which is only made > visible if the source including it has arranged to build with the > appropriate API compatability level. > > This doesn't seem to be documented in places I would consider obvious, > but it is seen in a comment in openssl/opensslconf.h: > > /* > * Applications should use -DOPENSSL_API_COMPAT=<version> to suppress the > * declarations of functions deprecated in or before <version>. Otherwise, > they > * still won't see them if the library has been built to disable deprecated > * functions. > */ > > There's also a related note in the CHANGES file: > > > *) 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] > > > That says that deprecated APIs should still be supported by a default > build of OpenSSL, and indeed I believe that's how NetBSD installs it. > > However it doesn't help for www/squid3. That's because its configure > script does not add "#include <openssl/ssl.h>" to the test program. > > It may also be useful to add a line like this to www/squid3/Makefile, > but of course that won't actually make it work -- it'll just document > that it needs at least OpenSSL-1.0.0: > > CFLAGS+= -DOPENSSL_API_COMPAT=0x10000000L > > The configure script will still need to be patched. > > Of course as mentioned squid-3 is heading on to old and should soon be > replaced by all users with squid-4, and especially pkgsrc should > deprecate squid-3 and provide the latest squid-4 by default. > > -- > Greg A. Woods <gwo...@acm.org> > > +1 250 762-7675 RoboHack <wo...@robohack.ca> > Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>
