Great, I'll proceed with changing ab.c to remove the hack, since it is unneeded when ab.c is compiled by the same toolchain as libcrypto.dll, isn't available in non-openssl distributions, and was deprecated in 1.1.1 again.
Anyone interested can proceed to patch both and provision applink.c when working with OpenSSL 1.1.1, so I don't need to raise a ticket at that project. On Fri, Oct 12, 2018, 16:37 Steffen <i...@apachelounge.com> wrote: > Already for years we have in server/main.c : > > #include "applink.c" > > > This solves errors like: no OPENSSL_Applink , see for example : > https://www.apachelounge.com/viewtopic.php?p=30986 > > No problem to patch. > > Op 12 okt. 2018 om 22:03 heeft William A Rowe Jr <wr...@rowe-clan.net> > het volgende geschreven: > > ... and still hanging. > > Rather than ApacheLounge and some others needing to patch each time, > did we conclude that we should wire in the applink.c stub into Apache.exe > as shipped by httpd project? > > (I've never mixed binaries of different MSVC environments, so myself, > I don't care, but it seems to raise issues for a subset of the community.) > > > On Mon, Sep 17, 2018 at 7:05 PM William A Rowe Jr <wr...@rowe-clan.net> > wrote: > >> 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. >> >
