No, sorry I am still confused on just which we're talking about here,
support/main.c or ab.c (which I was thinking) or both? Looking over this
thread on and off list seems to be a merge of both. So because of that;
-1 to adding to applink to support/main.c. httpd.exe isn't even linked
to ossl.
For abs.exe specifically, this all started here:
https://www.apachelounge.com/viewtopic.php?t=7134
and continued in PR 59630.
I just tested a AH vc14 build of 2.4.20 from 4/2016 and
C:\Apache24\bin>abs https://google.com/
OPENSSL_Uplink(00007FF8EB479000,08): no OPENSSL_Applink
So it was a problem at one time. Today I did a vc14 x64 builds of
current abs with the include line for applink commented out for all
current ossl versions and none of the three fail.
Then I did a 2.4.20 build with ossl 1.0.2p and no error. Next one with
1.0.2p and apr/u 1.5.x (as the 4/2016 build was) and again no fail. Next
apr/u 1.5 and ossl 1.0.2g (exact same as the 4/2016 build) and
C:\Apache24\bin>abs http://google.com/
OPENSSL_Uplink(00007FF900589000,08): no OPENSSL_Applink
So Bill as you eluded to somwhere in all the tl;dr in this thread you
are correct and openssl was the problem and it does seem fixed now.
Spending much of my day on this I've found applink.c began in 0.9.8. I
think it's always been in the ms folder and just copied to
include(inc32)/openssl during the building process.
So knowing all this I'm now +1 on removing the applink include in ab.c.
Cheers
On 10/13/2018 11:22 AM, William A Rowe Jr wrote:
On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith <g...@gknw.net> wrote:
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.
I can assure you that was not true, having built against 0.9.7, .8, 1.0.0,
etc etc etc. What can break is that if you build openssl in a different
model
(the whole /MD, /MT etc) than abs.c, then yes, they could be disjointed.
Can you find me any pointers to the claim that I could investigate further?
.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.
No, I'm certain that's incorrect. It was always in ms/ in the source bundle
and was previously installed into include/openssl/ on applicable platforms.
The fact that it isn't in the resulting installed -devel tree suggests it
is no
longer recommended, or that the openssl maintainers got the refactoring
of their build schema wrong.
I'm -1 on this till at least the majority of OSSL versions do not
include applink.c.
I read this as logical converse, you are +1 to patch main.c to include it?
This suggests we need to re-raise the issue at the openssl project or
declare 1.1.1 incompatible without the workaround of finding the library
source bundle, or manually installing applink.c where it used to be.
