I've been working on getting Serf built on Windows x64 with OpenSSL 1.1.0. I noticed that the function checks in SCons (Config.CheckFunc) that we use to find OpenSSL features were not working correctly. After some digging around in OpenSSL import libraries, SCons sources and the config.log file, I found the following:
1. Behaviour of Config.CheckFunc(function[, header]): SCons generates a test program that contains a call to 'function()'. This turns out to be quite problematic. 2. CheckFunc without the optional header parameter: When the test program is built, the compiler issues a warning about a missing prototype for 'function', assumes it's an "extern returning int". However, linking fails because the linker looks for the decorated function name '_function', but the names exported from the OpenSSL libraries (static or DLL import lib) are not decorated, so, just 'function'. The names don't match, the link fails and SCons happily assumes that the function does not exist. 3. CheckFunc /with/ the optional header parameter: The compiler now sees the function prototype and, since most functions require parameters, errors out because the call to 'function()' as generated by SCons is invalid. Again, SCons happily assumes that the function does not exist. 4. Conclusion: I do have an opinion about Windows name decoration that's not for public consumption. But in this case, I think that SCons is simply doing the wrong thing by blindly generating the function call. For comparison, autoconf does the same *but* also generates a prototype that overrides any compiler builtins, and doesn't include any headers in the test program. Finally, has anyone successfully built 64-bit Serf with OpenSSL 1.1.0 on Windows? If yes, how? Because I can't think of how this could be possible with SCons failing the way it does. FWIW: a 32-bit build of Serf and OpenSSL works. -- Brane