Exception loading ssleay32 with Indy10 with HTTP Server

1.4k views Asked by At

I'm trying to implement SSL support on my HTTP server and I'm getting an exception when I activate the server component:

The ordinal 3314 could not be located in the dynamic link library "ssleay32.dll".

This is an application that I ported from Delphi 2007 to Delphi XE7. It had been working in 2007.

Here's what I've tried:

  • Got the latest OpenSSL DLLs. Same error

  • Created a new XE7 test project that was simply a form with the HTTPServer and OpenSSL IOHandler components. It worked.

  • I'm not using the visual components in my primary app; so I thought I'd try creating a form in the primary app. I added the appropriate components, and it failed with the same error.

  • Since the project was ported from D2007, I thought there may be settings in the old project that may be interfering. I created a new DXE project and imported the forms, units, etc. Same error.

  • I thought possibly my manually generated code may be incorrect, so I copied it over to the test DXE project; and it worked.

I did discover the error is being thrown by a call to LoadLibrary in SafeLoadLibrary in System.Sysutils.

My only conjectures are.

  • There's a setting somewhere interfering with correct operation.

  • There's a path to a supporting DLL that is missing

Any ideas?


It turns out I have old libeay32.DLL and ssleay32.DLL (for Indy9) in the same folder as the EXE, and the latest versions in a sub-folder. I'm using IdOpenSSLSetLibPath to set the path to the sub-folder, but something must be loading the old libeay32.DLL prior to the Indy components. For historical reasons, I need to support both - I've still got some D2007 code running with Indy9 components. Any thoughts on how I can support this scenario (short of rewriting a lot of old code to use Indy 10)?

1

There are 1 answers

0
Kevin Koehne On BEST ANSWER

Turns out I had included one of our internal libraries that uses the Synapse TCP/IP library. Its SSL implementation loads the DLLs during initialization, which were the DLLs installed at the root of the application. When Indy tried to load the latest, it failed. There didn't appear to be any way to override the path for the DLLs in Synapse, so I modified the source to load them from the sub-folder.