libea32.dll error on install

[brinkyblob]

I just installed lazpaint for the first time and encountered an error complaining about libeay32.dll (in an odd "...\Intel\iCLS Client" folder). See attached screenshot.

It *seems* like everything is working, and it didn't complain when I launched the application for the second time, but I thought a developer might like to know.

[TRon]

Hi brinkyblob,

It *seems* like everything is working, and it didn't complain when I launched the application for the second time, but I thought a developer might like to know.

Everything should work because LazPaint itself does not rely on an internet connection nor does it install openssl libraries.

The error you got originates from Intels CLS client software (see also Intel Management Engine) which apparently installs or forces the use of a systemwide openssl library that the CLS client installer installs on your system.

The specific dll that you mention is part of openssl and seem to be corrupted or is the wrong bitness on/for your system.

LazPaint does try to connect to the internet (I believe to see if there are updates) and tries to do so by using a secure connection. For that to work it tries to open a secure socket and which depends on what options your OS provides which seem to be openssl as installed by Intels CLS client.

If you wish to get rid of the message completely then download the openssl libraries and manually copy the openssl dll files (of the correct bitness 32 bit vs 64 bit depending on what version of LazPaint you just installed)  next to your LazPaint executable.

[rvk]

Intels CLS client probably sets itself in the Windows PATH.

Then, every software searching for the openssl dlls will find them there 

lazpaint is probably 64-bit but will fail at loading a 32 bit openssl dll which is in that Intels CLS client directory.

I don't know which is worse, Intels CLS client setting itself in the global PATH and including a normally used dll in specific bitness, or lazpaint not checking the bitness before loading it (and not including it's own).

PS. If you create software and you include a known dll in specific bitness then DON'T set your own directory in the PATH as it could cripple other software.

PPS. If your software depends on openssl make sure you don't rely on any random openssl dll found on the PATH. If you don't include your own, check the version before you are trying to load that random one (which FPC doesn't do).

[circular]

Hi @brinkyblob,

Thank you for bringing this error to our attention. It's heartening to know that despite the hiccup, you can still use LazPaint without any major consequences.

Delving into the technical details, LazPaint uses the fphttpclient and opensslsockets units provided by the Free Pascal Compiler (FPC). It is not clear whether these units can be refined to manage the configuration as @rvk suggested, or if the resolution lies in adjusting the configuration as proposed by @TRon.

The unit responsible for the online request in LazPaint is uonline.pas. If you have insights on how to navigate this issue, your contribution would be precious.

Considering possible solutions, here are a few options:

• Bundling OpenSSL: This would ensure compatibility but may lead to an increase in the size of LazPaint, considering that this dependency is typically present.
• HTTP without SSL: While this seems like a straightforward solution, GitHub does not permit unsecured connections.
• Using terminal command "curl": This would entail leveraging a command-line tool to fetch the latest version information.
• Removing version check: This would eliminate the error but could potentially limit user awareness of updates.

Furthermore, the URL being checked is on gitcdn.link, which, based on recommendations, should not query GitHub directly. However, this URL is currently non-functional, rendering the version check ineffective. Perhaps hosting a file on the LazPaint website containing version information is the most practical solution.

Thanks your input and looking forward to any suggestions you might have.