[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: svn commit: r1748461 - in /httpd/httpd/branches/2.2.x: ./ CHANGES support/ab.c

So we kind of left this hanging...

On Wed, Jun 15, 2016 at 2:35 PM Gregg Smith <gls@xxxxxxxx> 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
> 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>

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.