philipp.hofmann 4 Posted April 4 Hi, I try to use the TSSLSmtpCli component (created during lifetime) on MacOS 64 (x86 and ARM). The files libcrypto.3.dylib libssl.3.dylib are deployed to Contents\MacOS\ So FileExists(ExtractFilePath(ParamStr(0))+'/libcrypto.3.dylib') FileExists(ExtractFilePath(ParamStr(0))+'/libssl.3.dylib') is true. But OpenSSL_version(0) returns an exception. So I assume the shared libraries are not initialized. How I can do this? For Windows this process works without any special requests beforehand. Best regards, Philipp Share this post Link to post
Angus Robertson 577 Posted April 4 Sorry, there is no official MacOS support for ICS, has not been for 10 years. If someone fixes it, I'll update it for the next release. Angus Share this post Link to post
philipp.hofmann 4 Posted April 4 The first thing I found now, you need: GSSL_PUBLIC_DIR:=TPath.GetDirectoryName(ParamStr(0)); IcsLoadSsl(); And you need to deploy to Contents\MacOS\usr\lib But now I get the error Can not find: RAND_screen Share this post Link to post
Angus Robertson 577 Posted April 4 RAND_screen is one of hundreds of entries loaded, it's been in OpenSSL for ever, but not actually used by ICS (I believe). If the files loaded are incorrect, there is usually a much longer list of missing entries. Angus Share this post Link to post
Remy Lebeau 1436 Posted April 4 RAND_screen was deprecated in OpenSSL 1.1.0 and hidden behind compatibility macros. So it is possible that it doesn't even exist in your copy of the OpenSSL libs. Share this post Link to post
Angus Robertson 577 Posted April 4 The OpenSSL DLLs we supply still contain deprecated entries since older applications may use them. But loading entries is table driven by version, so adding a literal to the table will stop it for v3. Was it just one missing entry, or many? Angus Share this post Link to post
philipp.hofmann 4 Posted April 4 OverbyteIcsSSLEAY.pas: You should use the following file names for 300DLL_Name (so no /usr/lib-path in the filename plus adding version number): {$IFDEF POSIX}'libcrypto.3.dylib';{$ELSE} { !!!! not tested, unknown file name } {$IFDEF POSIX}'libssl.3.dylib';{$ELSE} OverbyteIcsLIBEAY.pas: It works if I uncomment @@RAND_screen in the table (and reduce the number by 1): GLIBEAYImports1: array[0..852] of TOSSLImports = ( // (F: @@RAND_screen; N: 'RAND_screen'; MI: OSSL_VER_MIN; MX: OSSL_VER_MAX), I saw afterwards the correct OpenSSL-Version number with OpenSSL_version(0) -> 3.2.1 But there is still a problem in initialization of TSSLSmtpCli.create(nil); It's working fine unter Windows again. So I will check this as the next point. So I'm not sure if my idea to replace Indy-TIDSMTP with ICS-TSSLSmtpCli to support MacOS64-ARM was so good because I can't find MacOS-ARM-Libraries for OpenSSL-1.0.x. 1 Share this post Link to post
philipp.hofmann 4 Posted April 4 (edited) Now my problem is the request TSSLSmtpCli.create(nil); or also TSSLSmtpCli.create(mainForm); freezes in procedure TIcsMessagePump.AfterConstruction; with the following request: GlobalSync.BeginWrite; But even if I remove GlobalSync.BeginWrite at all SSLSmtpCli.connect is not reacting as expected as "SSL handshake faild - No error returned, State: SSLv3/TLS write client hello, connection closed unexpectedly" is raise after 60 seconds. The same implementation works fine under Windows. P.S.: I was misleading by https://wiki.overbyte.eu/wiki/index.php/ICS_Download as there is a MacOS support mentioned for ICS-V9. Edited April 4 by philipp.hofmann Share this post Link to post
Angus Robertson 577 Posted April 5 I can fix the OpenSSL issues, however the GlobalSync functions are part of the Posix message handling unit which is MacOS only, so I can not debug it. It was written many years ago and may need updating for newer MacOS versions. Other users have had the MacOS version of ICS working in recent years, and I do add changes they suggest. But not heard from MacOS users in a couple of years. Angus Share this post Link to post
philipp.hofmann 4 Posted April 5 I have deactivated GlobalSync now first. That's fine for me. But can you fix also the "SSL handshake faild - No error returned, State: SSLv3/TLS write client hello, connection closed unexpectedly" issue? This is currently my blocker. Share this post Link to post
Angus Robertson 577 Posted April 5 Sorry, that error could be the result of dozens of issues, you need to know that messages are being processed correctly first, without a message pump ICS simply does not work, and that is the main difference between Windows and MacOS. Try accessing the same site using a Windows sample, to see if the problem is unrelated to MacOS. Angus Share this post Link to post
philipp.hofmann 4 Posted April 5 It's 100% fine with the Windows sample with the same code. Share this post Link to post
Angus Robertson 577 Posted April 5 Thanks, so almost certainly the Posix/MacOS messaging stuff. Another user did make some minor changes to the Ics.Posix.PXMessages unit in preparation for Linux support, you could try reverting to the V9.0 version of that unit in case it got broken. Angus Share this post Link to post
philipp.hofmann 4 Posted April 7 I've found only one difference here and this could not be an issue for MacOS: {$IFDEF ANDROID} {$MESSAGE 'TODO processmessage loop'} Result := False; // Error { V9.1 } {$ENDIF ANDROID} But I've checked the reason for the blocker in function TMultiReadExclusiveWriteSynchronizer.BeginWrite: Boolean; is the line as here it's not coming back: WaitForWriteSignal; P.S.: TIcsMessagePump.ProcessMessage is not reached under MacOS, if this could be an issue here. P.P.S.: I assume it's an initialisation issue if such a central functionality as WaitForWriteSignal is not working and processMessage is not requested at all. But I don't know what to test further. Share this post Link to post
Angus Robertson 577 Posted April 7 All I can suggest is trying an older ICS version, if I've broken something in recent versions. Like https://wiki.overbyte.eu/arch/icsv868.zip There is a new Linux version V10 in SVN, but no SSL and only simple sockets at the moment, not tested on MacOS but it's uses a Delphi message pump which I assume works on MacOS, that version will be the long term cross platform version. But MacOS will only be supported if contributors help, we can not test it, no Apple hardware. Angus Share this post Link to post
philipp.hofmann 4 Posted April 8 Same effect with Version 8.68, so again I assume there is some additional piece of code necessary to initialize the MacOS-version of ICS but both of us don't know this part. Share this post Link to post
Angus Robertson 577 Posted April 8 Any other ICS MacOS users able to help here? Angus Share this post Link to post