Hi Tobias. That all makes sense. And you’re right, I had modified configure.ac to use crypto instead of eay32 and forgot to mention that in my original post. This was necessary since OpenSSL now outputs libcrypto and not libeay32 on Windows builds.
I think ideally the configure script would be updated to check for both versions (crypto first and then eay32) if older versions of OpenSSL are going to still be supported. Kevin > On Aug 24, 2017, at 1:34 AM, Tobias Brunner <[email protected]> wrote: > > Hi Kevin, > >> First, in my OpenSSL build I had set the ‘no-deprecated’ flag during >> configure, but apparently strongSwan is still using some deprecated >> functions. > > The plugin tries to work with pretty much any version of OpenSSL (and > BoringSSL, not so much LibreSSL at the moment). But these *SSL > libraries have been a real crapfest in regards to API changes in recent > years leading to lots of ifdefs and small wrapper macros. Could very > well be that there are some still missing for OpenSSL 1.1 (I guess the > distro versions of it are not compiled with no-deprecated, so somebody > needs to do some compatibly checks against different API versions). > >> But I’m still confused as to why I am seeing this problem when apparently no >> one else is. > > As I mentioned before, the Windows detection in the configure script > does not seem to work correctly on your system (otherwise there would be > an attempt to link libeay32 and not libcrypto - unless you changed that > in the script). This could mean that e.g. _WIN32 is also not defined. > Because if it was OpenSSL's ossl_typ.h header, included in x509.h, for > instance, would undefine the conflicting defines. > >> Could it simply be that no one else has built Windows strongSwan with the >> latest openSSL? That seems unlikely, though I guess possible. > > That's actually entirely possible as there are probably not that many > people building strongSwan for Windows. > > Regards, > Tobias
