Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm trying to use REST. So I'm using the TIdHTTP component. But it says 'Could not load SSL Library'.
What am I missing? My knowledge about SSL is zero.
I'm using Delphi 2007, Indy 10.1.5, and Windows 32-bit.
I put libeay32.dll and ssleay32.dll in my EXE directory (I found these DLL files at https://indy.fulgan.com/SSL/, file openssl-1.0.2t-i386-win32.rar).
type
TForm1 = class(TForm)
IdSSLIOHandlerSocketOpenSSL1: TIdSSLIOHandlerSocketOpenSSL;
...
procedure TForm1.btn_ReqCheckServerClick(Sender: TObject);
var
s: string;
lHTTP: TIdHTTP;
const
URL_CHECK_SERVER = 'http://example'; // some URL site to ping
begin
lHTTP := TIdHTTP.Create(nil);
try
lHTTP.IOHandler:=IdSSLIOHandlerSocketOpenSSL1;
IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Method:=sslvTLSv1;
lHTTP.ProtocolVersion:=pv1_1;
lHTTP.Request.ContentType := 'application/json';
lHTTP.HandleRedirects := True;
s := lHTTP.Get(URL_CHECK_SERVER);
ShowMessage(s);
finally
lHTTP.Free;
end;
end;
Does anybody know where the latest version of Indy can be download? At https://www.indyproject.org, many links are broken.
Indy's SVN repository is being retired. Indy's GitHub repository at https://github.com/IndySockets/Indy is now the active repository moving forward. Fulgan has recently turned off its sync between Indy's SVN and GitHub repositories.
Fulgan's nightly zip file at https://indy.fulgan.com/ZIP/ is no longer the latest dev snapshot of Indy (there have been a few check-ins to GitHub since the last time Fulgan pulled its snapshot from SVN). It has become redundant since users can pull zip files of Indy's source code from GitHub instead.
Indy will also soon be making a new GitHub repository for its OpenSSL lib binaries, which will be the final nail in the coffin for Indy's Fulgan mirror.
Indy's website at https://www.indyproject.org has not been updated yet to reflect this new information. Though there is a link to the GitHub repository in the download section for the dev snapshot.
You can go to the GitHub repository and grab the /Lib folder. You only need the /Lib/Core, /Lib/Protocols and /Lib/System folders at a minimum to compile Indy.
I'm trying to use REST. So I'm using the TIdHTTPÂ component. But it is not working. It says 'Could not load SSL Library'. I already read about this error from this forum, but still it is not working.
You can use Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why Indy could not load OpenSSL. Either the DLLs could not be loaded in memory, or the DLLs are missing exports that Indy requires.
Note, though, that 10.1.5 is an extremely old version of Indy, the latest version is 10.6.2. It is likely that 10.1.5 simply can't handle changes made to OpenSSL over the years since 10.1.5 was released. For instance, the removal of support for SSLv2 and SSLv3 is a likely culprit for an old version of Indy failing to load newer OpenSSL DLLs.
I am using :
Delphi 2007 (package version 110).
Windows 7.
Upgrade old Indy version ( Indy 10.1.5 ) to relative new Indy version ( Indy 10.6.2.5516 ).
Steps that I tried :
Component | Install packages... | Design Packages
point to Indy 10 Core Design Time, then click Remove button
point to Indy 10 Protocols Design Time, then click Remove button
delete all library path that refer to old Indy version
( Tool | Options | Environment Options | Delphi Options | Library - Win32 )
delete all IndySystem110.* IndyCore110.* and IndyProtocols110.* on PC.
open the individual DPK files in the IDE and I compile them, in the following order :
IndySystem110.dpk ( in Lib\System ) compile only.
IndyCore110.dpk ( in Lib\Core ) compile only.
IndyProtocols110.dpk ( in Lib\Protocols ) compile only.
dclIndyCore110.dpk ( in Lib\Core ), compile then install.
dclIndyProtocols110.dpk ( in Lib\Protocols ), compile then install.
Add Lib\System, Lib\Core, and Lib\Protocols to Delphi library path.
( Tool | Options | Environment Options | Delphi Options | Library - Win32 )
then I put libeay32.dll and ssleay32.dll with modified date 11/13/2015 7:55 AM both in my executable file folder location. It works !
Related
I'm trying to download a file with TIdHTTP.Get in Delphi Seattle. It's an app for android and all my attempts fails. All i get it's the same error "Could not load SSL library". This is the procedure:
procedure TfrmMain.DownloadPicture(const AURL: string);
var
MeS: TMemoryStream;
cidSSL: TIdSSLIOHandlerSocketOpenSSL;
cidHTTP: TIdHTTP;
begin
cidHTTP:= TIdHTTP.Create(nil);
cidSSL:= TIdSSLIOHandlerSocketOpenSSL.Create(nil);
Mes := TMemoryStream.Create;
try
cidHTTP.ReadTimeout := 30000;
cidHTTP.IOHandler := IdSSL;
cidSSL.SSLOptions.Method := sslvSSLv3;
cidSSL.SSLOptions.Mode := sslmUnassigned;
cidSSL.StartSSL;
cidHTTP.Get(AURL, Mes);
except
on E : Exception do
begin showmessage('Error: '+E.Message);
end;
end;
Mes.Position := 0;
frmImage.Image.Bitmap.LoadFromStream(Mes);
end;
If you are NOT using Android 6 Marshmallow, OpenSSL should be working fine on Android. When you get the "could not load" error, you can call Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why OpenSSL could not be loaded. If your device does not have OpenSSL pre-installed, you can deploy the OpenSSL binaries with your app, and use Indy's IdOpenSSLSetLibPath() function to tell Indy where to load them from.
That being said, starting with Android 6 Marshmallow, Google no longer supports OpenSSL on Android. It has been replaced with a custom fork named BoringSSL, which Indy does not fully support yet (although some BoringSSL-related changes have been made to Indy after Seattle's release). So, if you are having trouble with using Indy SSL/TLS on Android 6, you can try upgrading to the latest Github snapshot to see if it helps.
BoringSSL makes some major changes to the OpenSSL API interface (dropping functions, changing data types, etc), so it is not backwards-compatible with existing OpenSSL code. But to make matters worse, BoringSSL uses the same library filenames as OpenSSL, and is pre-loaded at device startup, so it is not possible to deploy custom-built OpenSSL library binaries with your Android app. Android will simply use the pre-loaded BoringSSL binaries when the app tries to load the OpenSSL library filenames at runtime (regardless of whether you call Indy's IdOpenSSLSetLibPath() function).
Indy operates at the NDK level of Android, not the Java level, so to make Indy avoid BoringSSL would require users to either:
recompile the OpenSSL libraries with new filenames that don't conflict with BoringSSL (AFAIK no known version of this is available), and then update Indy to use those filenames.
compile the OpenSSL source code directly into their Android app. Indy is not currently setup to support static-linking of OpenSSL on any platform other than iOS, but this should be a minor change to update Indy's IdSSLOpenSSLHeaders_static unit with the relevant definitions if someone can produce viable .a files for OpenSSL on Android. I do know of at least one user attempting this route, but that user has not had success yet (errors getting the source code to fully link correctly).
switch to Android's higher-level Java-based crypto APIs. This is Google's preferred solution. But Indy does not support it at this time. Doing so would require writing a whole new set of TIdStack and TIdIOHandler classes for Android socket I/O and SSL/TLS, using JNI calls to access the Java APIs. But this has performance and threading issues that need to be dealt with.
So, there is no known viable workaround available at this time to make Indy SSL/TLS work on Android 6+.
Update: a user in the Embarcadero forums was able to find OpenSSL .so files that are compatible with Indy and work on Android 6:
https://forums.embarcadero.com/thread.jspa?threadID=211089
After many reports of my apps crashing if installed in Android 6 devices I've searched the net for some tips and the couple of needed .so compiled files, 1.02 version, added the two files to the play store deployment of my apps (assets\internal) and changed the Indy's path calling
IdOpenSSLSetLibPath(TPath.GetDocumentsPath)
in the OnCreate of my datamodule.
After those modifications of my code my Apps run perfectly on my brand new S7 with Android 6.0.1, and on all the other recent Android devices (tested using the Play Store deployment).
And now the Google warning pops up telling me that the OpsnSSL files deployed with my apps are not of the minimum required 1.02f version (or 1.01r).... and so my post in this forum.
...
Anyway you can download here the latest .so files, the ones that I deploy at this moment:
https://drive.google.com/file/d/0B7AxqW32K0oXWW9nUk9qaFpHT0k/view?usp=sharing
Another user in the same discussion also seems to have some success as well:
Ive been running on android 6 loading the .so libraries just fine for months. The new problem is we need to compile new versions of the openssl libraries. Cygwin is not working correctly to compile for me so im switching to a linux install to create them (if possible) https://wiki.openssl.org/index.php/Android#Build_the_OpenSSL_Library_2
heres a repository you can grab some current prebuilt ones https://github.com/emileb/OpenSSL-for-Android-Prebuilt.git
Update: The following (German) forum discussion provides OpenSSL 1.0.2g binaries for Android (and iOS Simulator) to registered users. They do not display the security warning in the Google Play store:
http://www.delphipraxis.net/188736-kompilierte-openssl-bibliotheken-fuer-android.html
OpenSSL 1.0.2g Android.zip
OpenSSL 1.0.2g iOS Simulator.zip
Update: the Android binaries for OpenSSL 1.0.2g are now available in the Embarcadero Attachments forum:
https://forums.embarcadero.com/thread.jspa?threadID=211147
Then, to load OpenSSL instead of BoringSSL, follow these steps:
Add the 2 .so files to your project deployment and set them to deploy to the .\assets\internal\ folder
add the System.StartupCopy unit as the first unit in your DPR's uses clause.
call IdOpenSSLSetLibPath(TPath.GetDocumentsPath) at app startup.
Update: OpenSSL 1.0.1t and 1.0.2h binaries are now in the Embarcadero Attachments forum:
https://forums.embarcadero.com/thread.jspa?threadID=211147
Update: the binaries have now been posted on Indy's Fulgan mirror:
http://indy.fulgan.com/SSL/
Update: Indy is no longer using the Fulgan mirror for hosting OpenSSL binaries. They are now in their own GitHub repo:
https://www.indyproject.org/2020/06/16/openssl-binaries-moved-to-github/
https://github.com/IndySockets/OpenSSL-Binaries
Just swap the TidHTTP component for TNetHTTPClient
Probably you have a new OpenSSL library and an older Indy version. Check this:
Indy 10 - IdSMTP.Connect raising "Could not load SSL library."
There are versions for 32/64 bits.
Make sure you have the correct version of the files.
See this FTP for correct version.
Other mirror for download binaries here.
I use this code and this works:
procedure TfPrecos.GetImageByUrl(URL: string);
var
Strm: TMemoryStream;
vIdHTTP: TIdHTTP;
cidSSL: TIdSSLIOHandlerSocketOpenSSL;
begin
IdOpenSSLSetLibPath(TPath.GetDocumentsPath); //libcrypto.so and libssl.so in ./assets/internal
vIdHTTP.IOHandler := cidSSL;
cidSSL.SSLOptions.Method := sslvSSLv23; // version 2.3
cidSSL.SSLOptions.Mode := sslmUnassigned;
cidSSL.StartSSL;
try
vIdHTTP.Get(URL, Strm);
if (Strm.Size > 0) then
begin
Strm.Position := 0;
try
Image1.Bitmap.LoadFromStream(Strm);
finally
end;
end;
finally
Strm.DisposeOf;
vIdHTTP.DisposeOf;
end;
end;
Tw days ago, I installed Windows 10 build 1709 16299.192 and Embarcadero Delphi 10.2.2 Tokyo.
Since I installed them, my applications can't load the Firebird client library at runtime.
If I have an exe file compiled with older Windows and Delphi 10.2.2, it works fine, but every exe file compiled with the new Windows and Delphi are not working.
If I test a connection through TFDConnection, it connects successfully, but when I run the application I get this error:
[firedac][phys][fb]-314 cannot load vendor library [c:\users\username\desktop\projectname\bin\fbclient.dll] The specified module could not be found
Hint: check it is in the PATH or application EXE directories, and has x86 bitness.
The path is correct, and the client library is for x86. The same application was working before installing Windows 10 build 1907 16299.192.
I tried DevArt UniDac and compiled as Win64, still have the same problem.
Reinstalling Windows and Delphi 10.2.2 (tested with 2 versions 25.0.28979.1978 and 25.0.29039.2004) still didn't help.
I think it's a permissions issue, but I don't know how to fix it. I gave bds.exe all permissions over all groups, but still not working.
I have only this code on my test application
procedure TForm1.FormCreate(Sender: TObject);
var
Path: string;
begin
Path := IncludeTrailingPathDelimiter(ExtractFilePath(Application.ExeName));
FDPhysFBDriverLink1.VendorHome := Path;
FDPhysFBDriverLink1.VendorLib := 'fbclient.dll';
FDConnection1.Params.Database := Path + 'FBDV3.0.FDB';
FDConnection1.DriverName := 'FB';
FDConnection1.Params.UserName := 'sysdba';
FDConnection1.Params.Password := 'masterke';
FDConnection1.LoginPrompt := False;
FDConnection1.Connected := True;
end;
Included Files and Folders in bin Folder:
plugins (Folder contain engine12.dll)
fbclient.dll
ib_util.dll
icudt52.dll
icudt52l.dat
icuuc52.dll
I just had to install the Microsoft Visual C++ 2010 Redistributable.
It took me hours of trying and trying many things, I couldn't find any clue what causes it, even by debugging deep into the FD sources (Delphi 10.4.2). Too bad there is no useful error message anywhere. But then I used SysInternals Process Explorer and found this dependency. Thanks to #Remy.
(Just copying msvcr100.dll didn't help in my case.)
Of course I cannot say if this would have helped here, but at least it could help many others. The symptoms were the same - it worked in the IDE (data explorer), but not in the compiled application, even though the dll was there.
By debugging I also verified that the error message asking for not only fbclient.dll, but also fbembed.dll, is not a sign of any wrong parameters: it is always looking for the second one if the first one cannot be loaded (not only if it is not found).
Using the latest Indy10 sources from subversion, installing in to Delphi XE4,
I get this error when I try to install "dclIndyProtocols180.bpl":
Error:
Can't load package C:\dev\..\comp\Indy10\Lib\Output\BPI\Win32\Debug\dclIndyProtocols180.bpl.
%1 is not a valid Win32 application.
The BPI\Win32\Debug folder in question contains these files:
dclIndyCore180.bpl
dclIndyProtocols180.bpl
IndyCore180.bpi
IndyCore180.bpl
IndyProtocols180.bpi
IndyProtocols180.bpl
IndySystem180.bpi
IndySystem180.bpl
How do I fix or work around this? I am not exactly new to Indy, or Delphi, but each time there's a new delphi release, there are interesting surprises for those of us who prefer to build from source code and track subversion rather than using that random point in time which ships with the Delphi XE4 installer.
As a general side question: Is there any place where the status of the Indy project's subversion code, compared with whatever Embarcadero ships in their products is noted, or recorded?
By default a new package in Delphi might automatically be 64 bit, or you may have built a dependency as a 64 bit BPL, but not have switched to 32 bit for that BPL and rebuilt it.
Also you might have folders in your Library path that allow 32 bit and 64 bit BPls to try to load each other, causing this issue.
I'm having a very similar problem to the one posed in this problem (having to connect twice on first load because of a "problem" loading the SSL dlls), except I'm pretty sure I'm using the latest version of Indy so the solutions proposed there do not solve my problem.
I am using Delphi7, and I selected not to install Indy from the Delphi7 installer since that version is incredibly obsolute. I did install Indy9 from latest SVN source before downloading and installing Indy10 (from SVN source), but I reconfigured the IDE and project settings to use the new Indy10 components/paths instead of Indy9. Clearly the project is using Indy10 to build as there are quite a number of methods I had to change to match all the Indy10 signatures to even compile.
My SVN repository for Indy10 is checked out from: https://svn.atozed.com:444/svn/Indy10/trunk/Lib and shows last commit revision of 4972, about 2 weeks ago--this does not look like "some really old version of Indy10".
I have downloaded OpenSSL 1.0.1e for Win32 from the binary build at http://opendec.wordpress.com/ (the location recommended from that other stackoverflow question I mentioned earlier) and put it in the same folder as my built .exe
Here's the code I'm using right now to open an SSL connection:
try
POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
Except
on e : EIdOSSLCouldNotLoadSSLLibrary do
begin
ShowMessage('Failed to load: ' + WhichFailedToLoad());
POP.Connect(Server,Port,Protocol,UserName,Password,TimeOut);
end;
end;
BUT... this is causing an EIdOSSLCouldNotLoadSSLLibrary exception, and adding WhichFailedToLoad shows the exact same list of components, that would suggest it's expecting the "indy specific" version of OpenSSL:
But Wait a minute... Remy answered in the linked question that "Indy 10 was updated to no longer require the custom-built DLLs anymore. It now uses the standardized OpenSSL DLLs as-is." So why would it be complaining that it needs Indy specific functions?
How could I troubleshoot why it's failing to connect the first time/saying it needs functions I understand not to be needed anymore? Is my expectation that it should not be looking for indy specific functions incorrect?
My guess, confirmed in the comments to the question, is that your compiler is finding Indy 9 and not Indy 10 to build your project.
The things can go ever worst, because your IDE may be using one version in design time and the compiler may be using a different version. In fact the IDE and the compiler are different parts of the chain and you can broke the original synchronization between both. Because that, I'll explain both cases and, as I explain later, you have to change both.
The IDE and design time
Design time packages are loaded by the IDE to create objects while you're working, show you the properties of that objects in the object inspector, create the form DFM files and get the method firm to be used when you resort to the IDE to generate pascal code to respond to events.
For the IDE you can check what version you're using in design time by right clicking on any Indy component, as shown in the image.
To change the version you're using in design time, go to Component\Install packages and check the correct version in the list. You cannot load Indy 9 and Indy 10 at the same time.
The compiler and run time
The compiler uses the Library path to look for the units you use in your project that are not part of the project itself, and compile that code along with yours to produce the executable.
To check what Indy version was linked into your executable, you can resort to the Version property present on all INdy components, for example:
ShowMessage('Indy version: ' + MyIndyComponent.Version);
To change what the compiler finds first, you have to change the paths. You can do it from inside the IDE. In modern Delphi you could check in Tools\Options\Delphi options\Library\Library path\ and Project\Options\Delphi compiler\Search path\ (I just don't remember where the options were in D7).
The Indy 9/10 case
Indy introduced interface breaking changes that makes impossible to compile a project written for Indy 9 using Indy 10. In fact, the administrators of the project doesn't wait for a major release to break the code compatibility and you expect to be forced to adjust your code when you upgrade to any minor version if it happens to have a different interface.
Because of that, you're definitely using Indy 9 in both, at compile/run time and IDE/design time, so you have to adjust both in your environment. After that, be prepared to re-write part of your code to adjust. Once you understand what changed and learn how to adapt, the change is fairly simple. The details are out of the scope of this answer, but there's enough information in the Internet for you to figure out how to do it.
This question already has an answer here:
Step by step upgrade of Indy 10 in Delphi 2009
(1 answer)
Closed 3 years ago.
Is there a step-by-step guide for updating the Indy 10 components in Delphi 2009?
I've read the uninstalling thread and have the latest build (IndyTiburon.zip). However there appears to be no installation instructions.
If you have accomplished this, please share the details.
Edit: I have managed to get the packages installed by messing with the "requires" section in dclIndyProtocols120 and dclIndyCore120.
Essentially removed all Indy package dependencies from "requires" section and just used the Library path resolve things. Added ..\Lib\Core, ..\Lib\System and ..\Lib\Protocols to the Lib path. Had to leave dclIndyProtocols120 in requires for dclIndyCore120 as it wont install without this.
All 3 packages compiled (including IndySystem120) and seems to be working okay now.
This should be easier for D2009 users. I had to update to resolve an SMTP bug in Indy (see link).
On this question there is a more satisfying answer.
For all versions before D2009 you can use a Fulldx.bat script to recompile the packages and then just open the BPL files in (for example Indy-10.5.5\D6\dclIndyCore60.bpl and Indy-10.5.5\D6\dclIndyProtocols60.bpl) in the Delphi 2009 IDE packages dialog. Now with Delphi 2009, the FullD12.bat is there but it is not doing anything.
My simple solution is to create Indy components at run time only. I add the Indy Tiburon Core, System and Protocols to the projects search path, and also use Apache Ant with a build script to run the compiler for the final build.
One IIRC needs to compile system core and protocols in that order.
Moreover a package is a .BPL and a .DCP. So you probably would have to copy the .bpl and the .dcp to that directory in a normal case. The .BPL is what programs need to run, but to compile something that uses the .BPL (statically) you also needs the .dcp.
But that doesn't work for the Indy caseafaik because it also needs includefiles, so you need to add all their paths to the library path.
IIRC is that Delphi (at least the versions that I know) don't add directories to paths when installed, and one must always add paths to directories with .dcp or .dcu's manually.
(contrary to Lazarus that builds a list of dirs from the installed packages. But partially that is maybe also a fix for not having something akin .dcp yet, and in generally be more source oriented)
Note that I don't have D2009, it is just experience from general manual Indy compilation.
Maybe a simple method for anyone looking 10 years later... (tested under Delphi XE5):
Download the latest Version from https://indy.fulgan.com/ZIP/.
Extract the ZIP-archive into a folder of your choosing (I made a folder "Delphi Lib" under my Documents).
Throw out all Indy .dcu Files (Indy[...].dcu and Id[...].dcu) from your Delphi installation (for Example: C:\Program Files (x86)\Embarcadero\RAD Studio\12.0 (The last folders name may vary on your installation))
Open Delphi and go to Tools -> Options. Get to the "Library"-Listing and add the following folders of your newly downloaded Indy: /lib/Core/, /lib/System, /lib/Protocols.
As always: Help yourself and make backups before deleting anything. You do not want to reinstall your comlete Delphi because you threw away a file you should've kept...