fphttpclient. set path openssl libs

[RDL]

Hello.

Code: Pascal  [Select][+][-]

1. uses fphttpclient, openssl;

Is it possible to specify the path to load the openssl libraries
For example from C:\Users\User\AppData\Local\Temp

[paweld]

Code: Pascal  [Select][+][-]

1. uses
2.   fphttpclient, openssl, opensslsockets
3.  
4. procedure TForm1.FormCreate(Sender: TObject);
5. begin
6.   openssl.DLLSSLName := 'D:\ssl\ssleay32.dll';    //<-- set path to openssl
7.   openssl.DLLUtilName := 'D:\ssl\libeay32.dll';
8. end;
9.  
10. procedure TForm1.Button1Click(Sender: TObject);
11. var
12.   hc: TFPHTTPClient;
13. begin
14.   hc := TFPHTTPClient.Create(nil);
15.   hc.AllowRedirect := True;
16.   Memo1.Lines.Text := hc.Get('https://duckduckgo.org');
17.   Caption := openssl.SSLeayversion(0);
18.   hc.Free;
19. end;

[Thaddy]

It is a very bad idea to specify specific locations for libraries.
They should be in the correct directories:
In the case of windows:
\windows\sysWOW64 for 32 bit and \windows\system32 for 64 bit. This is not a typo! as I explained many times before on this forum.

On linux the libs should be in /usr/lib or usr/local/lib or a subdirectory of those.

In all cases the OS will find the right one to use, even bitness.

All a bit basic....

[Warfley]

It is a very bad idea to specify specific locations for libraries.
They should be in the correct directories:
In the case of windows:
\windows\sysWOW64 for 32 bit and \windows\system32 for 64 bit. This is not a typo! as I explained many times before on this forum.

On linux the libs should be in /usr/lib or usr/local/lib or a subdirectory of those.

Only libraries managed by your system (i.e. updated by system tools like windows updater or Linux package manager) should be in your system directory. The worst thing that can happen is that some software installs their libraries system wide, with a specific version, then another application does the same, with another (older/newer) version and now the original program doesn't work anymore.
This attitude of just dumping all DLLs in the system folder is where the term DLL Hell came from.

When you deliver your own libraries, you should rather put the dlls in the program folder on windows or set LD_LIBRARY_PATH in linux (or even better, package your app with Snap, Flatpack or Docker)

[Thaddy]

On the contrary:
dll hell is - always- caused by not reading manuals.
I thought you knew better.
If anybody would have followed procedures, there is no hell at all...

[xinyiman]

https://blog.lazaruspascal.it/2023/05/18/creare-un-web-server-https/

Hi, here is my guide on it. It's in Italian, but with an online translator you should be able to understand it.
Good work

[PascalDragon]

It is a very bad idea to specify specific locations for libraries.
They should be in the correct directories:
In the case of windows:
\windows\sysWOW64 for 32 bit and \windows\system32 for 64 bit. This is not a typo! as I explained many times before on this forum.

If a Windows application uses a specific version of the OpenSSL libraries they should be provided with the application at the location of its binary. The OpenSSL libraries on Windows are not versions thus two different applications copying their OpenSSL libraries to the system directories would lead to problems for one of the two.

[RDL]

Thanks to all contributors and special thanks to paweld for answering the question. 

[Warfley]

On the contrary:
dll hell is - always- caused by not reading manuals.
I thought you knew better.
If anybody would have followed procedures, there is no hell at all...

From the wikipedia entry:

The problem arises when the version of the DLL on the computer is different than the version that was used when the program was being created. DLLs have no built-in mechanism for backward compatibility, and even minor changes to the DLL can render its internal structure so different from previous versions that attempting to use them will generally cause the application to crash.

And under solutions:

An easy manual solution to conflicts was placing the different versions of the problem DLL into the applications' folders, rather than a common system-wide folder.

The problem is, you do not know what other software may be running on the end users computer, and what libraries they might have installed themselves, or through other software. Meaning, if you install a custom version of a library system wide, you don't know what other versions you may override and what you break by doing so. Applications should try to cause as little disturbance to the system they run on as possible, meaning you should have build them as self contained as possible.

And what procedures do you mean? Lets say you are a user and you have two applications, one ships and requires a library on version 1.0, the other one on 1.2. Each program does not work with the other version of the library, and both programs install the library in the system directory.
What procedures could have been taken here to avoid this (other than at least one of those not installing their library system wide)?