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.
