OpenSSL-Libs für MacOS64 ARM-Plattform

[philipp.hofmann]

Hi,

wo komme ich an die OpenSSL-Libs für die MacOS64 ARM-Plattform?
Gibt es dafür einen Download-Link?

[Rollo62]

Das ist nicht mehr ganz aktuell, aber trotzdem interessant.
https://github.com/grijjy/DelphiOpenSsl

Ich vermute mal, Du hättest gerne Libraries für M1 ARM, richtig?
Die habe ich auch noch nicht gesehen.

Vielleicht hilft das irgendwie weiter, ist aber ausdrücklich nur für Intel-Simulator.
[URL="https://delphiworlds.com/2016/03/building-openssl-dylibs-for-ios-simulator/"]https://delphiworlds.com/2016/03/building-openssl-dylibs-for-ios-simulator/[/
URL]
Es könnte aber möglich sein, sich die irgendwie selbst mit XCode zu compilieren ( O Gott, mit wird schon schlecht, wenn ich nur daran denke :oops: )

[philipp.hofmann]

Ja, ich habe an sich auch noch andere eigene Libs, die ich eigentlich auch kompilieren muss. Also eigentlich nicht so schlimm dies für OpenSSL auch zu machen. Ich hatte nur die Hoffnung, dass diese zentral irgendwo zur Verfügung stehen und ich mich um das andere Thema später kümmern kann. So wird am Ende 80% des Aufwandes der Portierung zu MacOS64-ARM die Libs-Kompilierung. Aber danke schon mal.

[philipp.hofmann]

Das Thema bleibt leider frustierend:
- für OpenSSL 1.0.2 gibt es keinen MacOS64-ARM-Support
- OpenSSL 3.2.1 habe ich schon mal für MacOS64-x86 generiert und initialisiert bekommen, es scheitert aber noch beim E-Mail-Versand via ICS
(ein paar Bugfixes habe ich eingereicht, aber hier wird es mir jetzt eine Runde zu technisch)

- der nächste Versuch ist nun die Umstellung von Indy auf OpenSSL 1.1 (dem dazugehörigen Thread entnehme ich, dass es kein 5-Minüter ist)

[Rollo62]

Zitat:

Zitat von philipp.hofmann (Beitrag 1535378)

- OpenSSL 3.2.1 habe ich schon mal für MacOS64-x86 generiert und initialisiert bekommen, ...

Wenn Apple was nicht will ... :cry:

Ich glaube, Du müsstest über kurz oder lang auch MacOS-ARM anbieten, wie käme man denn da dran?

[philipp.hofmann]

Die Lib für 1.1 und 3.2 kann man schon generieren. Ich hatte mit 3.2 nur aufgehört, weil ICS nicht wirklich Mac-fähig ist (entgegen der Version 9 Ankündigung). Ich habe jetzt zwar nochmals einen Fix vorliegen, den ich ausprobieren soll, aber dies mache ich später. Heute habe ich beim Wechsel auf Indy-10 mein Delphi 12 mal schön abgeschossen. Irgendwie kommt TMS damit nicht zurecht. Also alles neu installieren und Mut zur Lücke, direkt mal Delphi 12.1. Das Thema bringt mich noch um.
Und ja, irgendwie habe ich das Gefühl, dass die x86-Version auf den M3-Prozessoren deutlich weniger stabil läuft. Ich komme also nicht umhin, dafür eine Version anzubieten.

[philipp.hofmann]

So, ich habe jetzt die OpenSSL-Libraries Version 3.2.1 für MacOS64-x86 und MacOS64-ARM erfolgreich generieren können. Man muss das OpenSSL-Sourcen-Verzeichnis herunterladen und zweimal auf dem Rechner speichern. Einmal für x86 und einmal für ARM. Man kann nicht im gleichen Verzeichnis zuerst "./Configure darwin64-x86_64-cc ..." mit allen x86-Parametern aufrufen und dann "make" und danach dann ".Configure darwin64-arm64-cc" aufrufen (das geht noch) und dann wieder "make". Dies liefert dann einen Fehler. Man muss beides in den zwei Verzeichnissen sauber getrennt abarbeiten. Wer die Libs möchte, kann sich gerne melden.

Mit der OpenSSL-Version 1.1.1 wird man dies genauso generieren können.
Nur für OpenSSL-1.0.2 gibt es meines Wissens keine MacOS-ARM-Unterstützung.

ICS habe ich für den Mailversand unter MacOS leider nicht konfiguriert bekommen. Die OpenSSL-3.2.1-Libs werden sauber geladen, es blockt dann aber in
Ics.Posix.PXMessages.pas in der Funktion
function TMultiReadExclusiveWriteSynchronizer.BeginWrite: Boolean; beim Aufruf von

Delphi-Quellcode:

procedure TMultiReadExclusiveWriteSynchronizer.WaitForWriteSignal;
begin
  FWriteSignal.WaitFor(FWaitRecycle);
end;

Da steige ich leider aus, ich habe keine Ahnung, was man hier noch tun muss, um dies sauber zu initialisieren.
Ich habe es sowohl in ICS 8.68 als auch 9.1 ausprobiert.

Und der Wechsel auf Indy 10 mit 1.1-Unterstützung ist bei gleichzeitiger Nutzung von TMS-Software-Komponenten leider auch sehr aufwändig, weil man nicht nur die TMS-Komponenten neu installieren muss, sondern auch irgendwelche Projekt-Dependencies manuell pflegen muss, weil die Indy 10 und die Delphi-Indy-Libraries einem anderen Namensschema folgen. D.h. man muss auch alle TMS-Updates manuell einpflegen. Da ist mir dann leider auch die Lust vergangen, diesen Weg zu gehen.

Ich vermute es läuft dann jetzt auf die kostenpflichtige Komponente von ipWorks hinaus.

[Rollo62]

Interessant, das Kompilieren solcher Libraries habe ich bisher vermieden.
Ein Grund war meistens, dass solche Libraries VC oder andere Compiler benötigen.
Hast Du hierfür den RadStudio C++Builder genommen und kompiliert der out-of-the-box ohne weitere Frickelei?

(ich wette mal, Du hast dafür was anderes genommen)

Quatsch: Es ging ja um MacOS, dann muss es sowieso XCode oder die CommandLine Tools sein. Vergiss C++Builder ...

[philipp.hofmann]

Yepp, das geht alles über die Command Line unter MacOS und du musst nichts installieren. Nur das OpenSSL-Verzeichnis herunterladen, einmal darin ./Configure mit den passenden Settings aufrufen und danach "make". Das war es.

[philipp.hofmann]

Jetzt habe ich endlich die Libs mal unter die Leute gebracht, jetzt können zumindest Nutzer mit MacOS 12 und älter die neuen Libs nicht öffnen (13.x weiß ich noch nicht). Da muss ich also nochmals einsteigen und mir anschauen, wie ich die OpenSSL-Libs bis Catalina generiert bekomme. Die kurzfristige Lösung ist, dass ich jetzt wieder bei älteren MacOS-Versionen Indy mit OpenSSL 1.0 nutze. Die ARM-Version kommt erst noch und da gibt es dann nur die OpenSSL-Version 3.x, aber die Wahrscheinlichkeit, dass dort Nutzer ältere MacOS-Versionen haben, ist zumindest geringer.

Das ganze Thema OpenSSL gehört für alle angebotenen Plattformen echt in Delphi integriert, sprich sowohl aktuelle Code (da muss man sich dann eben finanzielle mit Indy einigen) und auch alle Libraries. Ein Krampf sich da selbst drum kümmern zu müssen.