On 06.07.2016 09:37, Stuart Douglas wrote: > Hi everyone, > > I am trying to implement a generic Java SSLContext that is backed by > OpenSSL that uses dynamic loading to link to OpenSSL. > > This works well on Linux, however I am running into "no > OPENSSL_Applink" issues on Windows. According to the FAQ all that > should be required is including openssl\applink.c, however this will > not work in my case as the main process is the java executable, and > not my glue library, so the uplink function is not finding it. > > Is there any way I can get this working? I have had a quick look at > the uplink code and as far as I can tell I am out of luck, but I am > hoping I have missed something. > > Stuart > If you take a look at the OPENSSL_Uplink() function (ms/uplink.c), you will see that the code gets the applink function pointer via apphandle = GetModuleHandle(NULL); applink = GetProcAddress(apphandle, "OPENSSL_Applink") i.e., OpenSSL expects the OPENSSL_Applink() function to be "DLL-exported" from the executable itself, see [1]. (If this sounds weird to you, don't worry, you're not alone ;-) In my opinion this is a design flaw which makes it almost impossible to have a wrapper dll around the OpenSSL library, since you always have to modify the excutable to be able to link. The back links are necessary, but the way they are obtained is bad design. The best solution for this would be to have an OpenSSL API call such as OPENSSL_register_applink(), which could be used by an executable or a shared library likewise. The only problem I see is to add the new api and stay compatible to the old hacky way. Maybe you should open a ticket on the rt for this. Regards, Matthias [1] MSDN - GetModuleHandle https://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx
