On 10/13/2018 8:32 AM, William A Rowe Jr wrote:
Sorry, I don't understand.
Gregg, can you shed some insight here? For both, applink.c is helpful if
the OpenSSL .dll files are created with a different VC compiler than
abs.exe was compiled with.
Not true, OSSL 1.0.2 I know from experience if applink.c is not included
it will still err even if both ab.c & OSSL are compiled with the same VC
version (14 & 15). I never tested 1.1.0.
.exe, it cannot be found from a .dll or Apache .so loadable.module.
Otherwise, I understand this to be a noop.
No, it just got moved to the ms folder is all that happened at 1.1.0 and
is still there in 1.1.1.
I'm -1 on this till at least the majority of OSSL versions do not
include applink.c.
OpenSSL project deprecated, that is, no longer ships applink.c in
include/openssl/ install directory. LibreSSL and BoringSSL have no such
resource.
Since you indicate that patching is trivial, and building with two
different compilers isn't something an open source project should fret
about, the Apache.exe and abs.exe should behave the same way. Pick one.
On Sat, Oct 13, 2018, 04:04 Steffen <i...@apachelounge.com> wrote:
Do not understand your writing.
abs.exe needs the applink shim, so leave it in.
Op 12 okt. 2018 om 23:54 heeft William A Rowe Jr <wr...@rowe-clan.net>
het volgende geschreven:
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 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.
