[Solved] Could not find OpenSSL Library

[BlueIcaro]

Hello, I making a small test with last Lazarus release in windows 11.

Code: [Select]

program Project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  Classes,
  fphttpclient,
  opensslsockets;

var
  HttpSend: TFPHTTPClient;
  Respuesta: TStringList;
begin
   HttpSend := TFPHTTPClient.Create(nil);
   Respuesta := TStringList.Create;
   HttpSend.Get('https://www.google.es',Respuesta);
   Writeln(Respuesta.Text);
   Readln();

end.     
When I run my program, I got the error: Could not find OpenSSL Library
I installed both OpenSll library 64 bits and 32 bits form here: https://slproweb.com/products/Win32OpenSSL.html. But I still the error

Thanks in advance

/BlueIcaro

[paweld]

OpenSSL libraries must be in the program directory (the best solution) or in the Windows\System32 directory (Windows\SysWOW64 - if 64-bit system and the library is 32-bit).
You also have to remember that Lazarus 3.6 is being released with FPC version 3.2.2, which supports OpenSSL versions 1.0.2 and 1.1 - it does not support version 3

[BlueIcaro]

Thanks Paweld. As you said I need version 1.1 or 1.0.2

Just I come to the forum, to said that I found the solution, but you was faster than me.

IF anyone needs it, I downloaded the files from here: https://wiki.overbyte.eu/wiki/index.php/ICS_Download

Thanks

/BlueIcaro

[Thaddy]

OpenSSL libraries must be in the program directory (the best solution) or in the Windows\System32 directory (Windows\SysWOW64 - if 64-bit system and the library is 32-bit).
You also have to remember that Lazarus 3.6 is being released with FPC version 3.2.2, which supports OpenSSL versions 1.0.2 and 1.1 - it does not support version 3

The correct solution is: in the Windows\System32 directory if it is 64 bit and in Windows\SysWOW64 - if 64-bit system and the library is 32-bit or must be in the program directory (the lesser solution, but OK during development)
So the other way around. That is a common and, frankly, disturbing mistake.
Always check if OpenSSL is correctly installed and always check the version.
The 64 bit openssl goes in windows32 <sic> and the 32 bit goes in sysWOW64. Keep the version up-to-date.
OpenSSL libs are known to be sourced from non-reputable sources. Just my two cents and don't write I did not warn you, again.
FPC 3.2.3 (fixes) supports openssl 3.X btw, it has nothing to do with Lazarus. I think 3.2.2 also supports it already because my bug report is over 5 years old.
When your code fails, you use a version where insecure protocols are dropped (all ssl, tls 1.0, maybe even tls 1.1 and tls 1.2)
That is a nuseanse, but a comfortable nuseance:It keeps your code safe.
And don't argue, makes you look stupid.

The biggest problem is your Windows is up-to-date and you are developing with an OpenSSL version that is way outdated.

- do not overwrite a version before you checked the version
- do only download OpenSSL from a reputable source, never use an included version thatb is distributed with an application

[paweld]

The correct solution is: in the Windows\System32 directory if it is 64 bit and in Windows\SysWOW64 - if 64-bit system and the library is 32-bit or must be in the program directory (the lesser solution, but OK during development)
So the other way around. That is a common and, frankly, disturbing mistake.

Personally, it pisses me off that most installers put the libraries into the system directories, and then after uninstallation you're left with all that crap in the system directory. In addition, sometimes it happens that the installer overwrites the library in the system directory with a newer / older version which causes other software to stop working / throw errors.
The best approach is to put the libraries in the directory with your application - from experience I will say that this solves a lot of problems.

I think 3.2.2 also supports it already because my bug report is over 5 years old.

FPC 3.2.2 nie wspiera OpenSSL nowszego niż 1.1

The biggest problem is your Windows is up-to-date and you are developing with an OpenSSL version that is way outdated.

He works with the version that the latest stable version of the development environment allows him to do.

[rvk]

The best approach is to put the libraries in the directory with your application - from experience I will say that this solves a lot of problems.

I completely agree (unlike Thaddy).

He says it's only ok for developers to put the dll in the exe directory but install it when distribute your program. I say it's the other way around. When I develop I often create a new program (in its own directory). In that case it's easy to have the dll in the system directory (or search path). But when you distribute it to a user then you definitely don't want to rely on a dll in the system directory. Yes, the correct one could already be installed there but some rogue program could overwrite it with an older one (i.e. openssl 0.9 ) and then your program suddenly doesn't work anymore. Users are going to blame your program (because it doesn't work anymore) not the newly installed crap program. Or a program can put an (future) openssl version 5 there (while your program can only handle version 3).

I can't imagine the number of phonecalls from my users if I would have relied on the openssl from the system directory. And because it's an older Delphi app (which can't handle 3.0 yet) it would crap out really quickly because other programs would replace that system openssl with a newer (or older) version. No folks... I say... Don't copy your dll to the system directory for users. Only for development (on your own computer).

The biggest problem is your Windows is up-to-date and you are developing with an OpenSSL version that is way outdated.

Of course your programs only run a year or two after which they get an update or the user stops using your program. I have users which use a version of my program which is much older.

(Hell, I still have some users on my DOS program.)

[TRon]

Personally, it pisses me off that most installers put the libraries into the system directories, and then after uninstallation you're left with all that crap in the system directory. In addition, sometimes it happens that the installer overwrites the library in the system directory with a newer / older version which causes other software to stop working / throw errors.

Which is an overall design flaw in the Operating System itself and even after all these years still not addressed.

[Thaddy]

'@TRon
Windows and Unixes have the same recommendations. Are they both flawed?
Of course not in this case, it prevents storage pollution and, to a certain extend, versioning.
That is the proverbial: it works for me, so if it works for me and someone wants to use my software, go to hell with conventions and please simply do what I tell you to make my software work. Spoiled child behavior.
There is not much difference between \windows and /usr

[TRon]

@Thaddy
Yes, they are both flawed in my opinion though the situation is slightly better for *nix' because of the stricter policies that are in place.

Please don't get me wrong there, the global approach is imho also the correct one but especially on windows that can make you life a living dependency hell (and that is what should have been addressed ages ago)

[rvk]

@Thaddy. How would you solve the issue of wrecking other apps if you install a newer openssl version to the system32 directory? How would you know which programs uses the older version and won't work anymore with the newer version?

What version do you currently have in your system32 directory of openssl, Thaddy?

[paweld]

That is the proverbial: it works for me, so if it works for me and someone wants to use my software,

This may come as a big surprise to you, but my software works regardless of whether the libraries are in the application directory or in Windows\System32 (checked from Windows Vista to Windows 11, in both 64-bit and 32-bit versions). And any that uses OpenSSL in conjunction with FpHttpClient, Synapse, or Indy will also work, since the existence of dll files in the system paths and the application path is checked when the library is loaded.

go to hell with conventions

Of course I do if I have to choose between conventions on one side and confidence that the application will work and order in the system on the other.

and please simply do what I tell you to make my software work.

Of course it does. There's nothing strange about that, and it's true of any software. Some require RDBMS to run, others java, others MS VC Runtime libraries, etc. If you don't meet these requirements then the software won't work.


As I wrote in my first post in this thread, I give customers alternative locations for the library files and everyone can decide where to put them - of course, I recommend in the application directory.

[Thaddy]

@Thaddy. How would you solve the issue of wrecking other apps if you install a newer openssl version to the system32 directory? How would you know which programs uses the older version and won't work anymore with the newer version?

What version do you currently have in your system32 directory of openssl, Thaddy?

That is not a point: shared libraries are shared. If you are an idiot you make your own location or otherwise simply link statically.
Most of you are idiots, as am I. But this is beyond belief.

[rvk]

That is not a point: shared libraries are shared. If you are an idiot you make your own location or otherwise simply link statically.
Most of you are idiots, as am I. But this is beyond belief.

You still didn't answer me !!

How would you deal with different programs needing different versions of openssl?
Would you overwrite an older version of openssl in the system32 (knowing some other program might need it)?
Or do you always link statically? (you always mention to use the system32/wow on this forum which goes against that advice.)