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

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

On Sat, Oct 13, 2018 at 12:00 PM Gregg Smith <gls@xxxxxxxx> 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.