So we kind of left this hanging... On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith <g...@gknw.net> wrote:
> On 6/15/2016 9:20 AM, William A Rowe Jr wrote: > > In building httpd.exe, some users don't build and install openssl. It > isn't > > going > > to be possible to simply #include<openssl/applink.c> without some > > conditional > > test. OpenSSL itself is partly the culprit, for not having an > > APPLINK_REQUIRED > > style macro conditional. But we can work around this in the cmake tests. > > > > This is why the patch creator put this inside a HAVE_OPENSSL block so > ab.exe did not get this added. abs (at least on the dsp et. al.) is not > built unless there is OpenSSL present. > > > I'll look at making this a standard bit of the httpd 2.4 build. We can > > likely > > add a user-toggled flag to the os/win32/os.h? > > Seems to me this is not needed . > So, is the win32 community in favor of using HAVE_OPENSSL to include applink.c in the scope of main.c (as revised in the current ab.c sources, to avoid this on libressl?) There is a presumption that the crt used by libhttpd the same as libapr, but I think this is a reasonable connection. The entire logic to main.c should be as simple as... #if defined(HAVE_OPENSSL) && defined(_MSC_VER) && !defined(LIBRESSL_VERSION_NUMBER) /* The following logic ensures we correctly glue FILE* within one CRT used * by the OpenSSL library build to another CRT used by the ab.exe build. * This became especially problematic with Visual Studio 2015. */ #include <openssl/applink.c> #endif By inserting the structure in httpd.exe, that structure can be found by the openssl library, which is not true of including this in a loadable library such as libhttpd.dll or libaprutil-1.dll.
