10.4.2: Indy IdSSLOpenSSL kaputt?

[Bbommel]

Moin zusammen,

nachdem die Installation von 10.4.2 gut ablief und alles zunächst einen guten Eindruck machte, endete diese Freude leider beim Versuch, ein bestehendes Web-Projekt zu kompilieren

Der Compiler gibt folgenden Fehler aus, wenn die Unit IdSSLOpenSSL eingebunden wird:

[dcc64 Fataler Fehler] WebControler.pas(8): F2051 Unit IdSSLOpenSSL wurde mit einer unterschiedlichen Version von IdSSLOpenSSLHeaders.PSSL compiliert

Zusätzlich gibt es noch die folgende Warnung (was mich wundert, denn offensichtlich versucht er, die Unit zu compilieren, obwohl die doch fertig im Lieferumfang ist?):

[dcc64 Warnung] IdSSLOpenSSLHeaders.pas(24799): W1044 Bedenkliche Typumwandlung von string in PAnsiChar

Ich hatte zuerste vermutet/gehofft, dass durch das Migrationstool vielleicht falsche Pfade übernommen wurden und er die Indys aus der Delphi 10.3-Installation sucht, aber das konnte ich bisher nicht bestätigen. Bevor ich daher den Fehler bei mir Suche: nutzt noch jemand die Indys mit SSL und kann das mal testen, ob da alles funktioniert? Falls nicht, würde ich es als Fehler melden. Oder hat sonst jemand eine Idee, woran es liegen könnte?

[Klaus01]

.. Build (shift F9) bringt auch keine anderen Ergebnisse?

Grüße
Klaus

[Daniel]

hm.
Ich habe hier ein einfaches Projekt gegriffen, welches sich mit Indy via SSL zu einem Server verbindet und dieses wurde unter Win32 und Win64 anstandslos vollständig kompiliert. Ich hatte zuvor nie was an den Indy-Komponenten gedreht, es müssen als die werksseitigen Komponenten sein.

[Bbommel]

Zitat:

Zitat von Klaus01 (Beitrag 1483770)

.. Build (shift F9) bringt auch keine anderen Ergebnisse?

Nein, leider nicht, hatte ich schon getestet.

Zitat:

Zitat von Daniel (Beitrag 1483771)

hm.
Ich habe hier ein einfaches Projekt gegriffen, welches sich mit Indy via SSL zu einem Server verbindet und dieses wurde unter Win32 und Win64 anstandslos vollständig kompiliert. Ich hatte zuvor nie was an den Indy-Komponenten gedreht, es müssen als die werksseitigen Komponenten sein.

Ich habe auch noch nie an den Indys "rumgespielt", insofern muss das bei mir auch alles werksseitig sein. Hm. Blöd.

Ich teste mal ein anderes und ein neues/leeres Projekt.

[himitsu]

Suchpfade falsch? Oder liegen irgendwo noch alte DCUs in alten/anderen Verzeichnissen rum?
z.B. es werden die 32 Bit DCUs zuerst gefunden, obwohl für 64 Bit kompiliert wird.

Eigene Indy-Installation oder die Indys im Delphi?

> Bedenkliche Typumwandlung von string in PAnsiChar
Vielleicht Version zu alt, die erkennt das neue Delphi nicht, denkt es sei was Altes und verwendet dann Code, der für Versionen vor D2009 gedacht sind.


Und ja, wenn in den Suchpfaden zuerst die Verzeichnisse mit den PAS gefunden werden, dann werden Diese genutzt, anstatt der vorkompilieren DCUs.
Schlimmes Chaos wird es hier schnell, wenn dann auch nicht alle PAS gefunden werden und ein Teil als DCU, womöglich noch vom falschen Compiler (andere Platform oder gar andere Version), genommen und ein Teil über PAS neu kompiliert wird.

[Bbommel]

Hm, verdammt, ich hasse es, wenn ich selber schuld bin. ;-)

Ich hatte zwar schon in den Suchpfaden geguckt, um da zu prüfen, ob ggf. in einem falschen Verzeichnis gesucht wird, aber nur in den globalen Suchpfaden, nicht in dem vom Projekt. Dort, also im Suchpfad vom Projekt, lag dann der Fehler: ich nutze die JOSE-Bibliothek von Paolo Rossi (https://github.com/paolo-rossi/delphi-jose-jwt), um JSON Web Tokens auszuwerten. In der gab es ein Problem mit der damals bei Delphi 10.3 mitgelieferten Version der IdSSLOpenSSL, weswegen ich eine gepatchte Version in dem Verzeichnis liegen hatte. Das passte dann jetzt alles nicht mehr zusammen.

Also: die von der 10.3 stammende und gepatchte Version der IdSSLOpenSSL entfernt und aufgeräumt und dann läuft alles.

Dennoch Danke für eure Unterstützung! :-)

[himitsu]

Im Prinzip wäre eine Compilerausgabe/Log mal ganz praktisch:
-> Welche DCU/PAS wurden von wo verwendet.

Da würde man dann "direkt" sehen was "wirklich" genommen wurde
und bei falschen Verzeichnissen wonach man dann suchen könnte.

Oder zumindestens der komplette Pfad in den Fehlermeldungen, anstatt nur dem UnitNamen, das würde auch helfen, aber die Log- und Fehlermeldungen wohl eher unleserlich lang machen.



Bei unseren eigenen Designtimepackages lasse ich seit 2-3 Wochen nun direkt ins Meldungen-Fenster ausgeben welches Package aus welchem Verzeichnis geladen/entladen wird.
Wir hatten in den letzten Jahren immer mal wieder "unerklärliche" Problemchen, wo unbemerkt beim Start oder beim Kompilieren was aus'm falschen Verzeichnis gelagen wurde.
Zusätzlich versuche ich zwar auch "doppelte" Dateien zu entfernen, aber erstmal für die Zukunft nun auch das Log, falls es wieder mal passiert.
Und da es beim Entladen von Packages vor/nach dem Compilieren auch manchmal knallt, sieht man nun nach welchem Package es passierte, da der Stacktrace in der IDE oft leider nicht hilft, da es nicht sofort knallt, sondern erst in einem nachfolgenden Post-/SendMessage (beim Debuggen der IDE).