Compilerfehler, aber wie Abhilfe schaffen

[skoschke]

Hallo,

beim Compilieren einer Komponente, welche auch eine DLL verwendet, bekomme ich folgende Compilermeldung:

[dcc32 Fehler] xxxxxx.pas(134): E1025 Sprach-Feature wird nicht unterstützt: 'Import von DLL-Symbol nach Ordinalzahl'

Scheint an so etwas zu liegen:

Delphi-Quellcode:

function GetLagerOrte(Items: TStrings): Boolean; external cDLL index 311;

Solche Deklarationen gibt es da über 100 Stück!

Das Originalprojekt stammt aus XE6, ich habe Delphi 10 Berlin.

Hat jemand einen hilfreichen Tip?

Ciao
Stefan

[taveuni]

Vielleicht so was wie hier?

[Der schöne Günther]

Merkwürdig, in Delphi 10.0 Seattle geht das noch. Er meckert zwar an "[dcc64 Warnung] Project3.dpr(10): W1002 Symbol 'INDEX' ist plattformspezifisch", aber sonst...

[TiGü]

Ist die Zielplattform anderes? Also 64- anstatt 32-Bit Windows? Oder ein anderes Betriebssystem?

[skoschke]

Das Originalprojekt wird mit XE6 unter Win7 compiliert, hier habe ich Win10 und Berlin

Ciao
Stefan

[skoschke]

Zitat:

Die Fehlermeldung "E1025 - Sprach-Feature nicht bekannt: object" erscheint, wenn man vom Compiler zusätzlich C/C++ - Ausgabedateien (Headerdateien etc.) erzeugen läßt, da C/C++ wohl keine Entsprechung zum Object kennt.

Abschalten dieser Meldung unter: Projekt -> (Standard-) Optionen -> Delphi Compiler -> Ausgabe C/C++ -> Erzeugung der C/C++ Datei, wähle: Nur DCUs erzeugen

Stand in dem Link zwar bei einer anderen Ursache, hat scheinbar aber geholfen...
Zumindest ist diese Fehlermeldung erst mal weg, komplett kompilieren kann ich allerdings immer noch nicht...

Ciao
Stefan

[hoika]

Hallo,

Zitat:

Zumindest ist diese Fehlermeldung erst mal weg, komplett kompilieren kann ich allerdings immer noch nicht...

Und welcher Fehler ist noch übrig?

[skoschke]

Etliche Proceduren, bei denen Objekte als const deklariert sind, die dann aber innerhalb der Procedure beschrieben werden!

Da kommt natürlich "der linken Seite kann nichts zugewiesen werden"!
Das scheint aber in XE6 noch kompilierbar gewesen zu sein, oder gibt es da auch noch einen Schalter der das zulässt?

Diese Dinge habe ich alle angepasst, das Package lässt sich compilieren, es entsteht auch die bpl-Datei, aber beim Installationsversuch kommt "das angegebene Modul wurde nicht gefunden!"

Die bpl existiert, aber auch bei Komponente / Installieren kommt besagte Meldung...
Welches Modul hat er da nicht gefunden?


Ciao
Stefan

[hoika]

Hallo,
dafür müsste es einen Compiler-Schalter geben.
De BPL ist ja eine DLL. Schau doch mal mit dem Dependency Walker, was dort an anderen Dlls verlinkt ist.

[peterbelow]

Zitat:

Zitat von skoschke (Beitrag 1429560)

Etliche Proceduren, bei denen Objekte als const deklariert sind, die dann aber innerhalb der Procedure beschrieben werden!

Da kommt natürlich "der linken Seite kann nichts zugewiesen werden"!
Das scheint aber in XE6 noch kompilierbar gewesen zu sein, oder gibt es da auch noch einen Schalter der das zulässt?

Nein. Aber normalerweise kann man ein Object als const-Parameter übergeben, wenn man innerhalb der Methode dann nur seine Properties ändert. Was man nicht ändern kann (und auch niemals tun sollte, wenn der Parameter nicht als var oder out deklariert ist) ist, dem Parameter innerhalb der Methode ein neues Objekt zuzuweisen. Das ist auch dann ein konzeptioneller Fehler, wenn der Parameter ohne const deklariert wurde.

Ich finde es übrigens sehr bedenklich, wenn eine DLL Funktionen exportiert, die Delphi-spezifische Datentypen wie TStrings verwenden. Sowas funktioniert normalerweise nicht ohne massive Probleme. DLL und Anwendung müssen auf jeden Fall mit der gleichen Delphi-Version kompiliert werden und sie müssen einen gemeinsamen Memory-Manager verwenden (z. B. in dem man beide mit run-time packages baut, und dann kann man auch gleich eine Package statt einer DLL erzeugen). Wenn man eine DLL haben will, die unabhängig von der Delphi-Version des Hostprogrammes ist und eventuell sogar von anderen Programmiersprachen aus nutzbar ist darf man nur API-Level Datentypen verwenden, oder zumindestens COM-kompatible.

[Rudy Velthuis]

Zitat:

Zitat von peterbelow (Beitrag 1429575)

Zitat:

Zitat von skoschke (Beitrag 1429560)

Etliche Proceduren, bei denen Objekte als const deklariert sind, die dann aber innerhalb der Procedure beschrieben werden!

Da kommt natürlich "der linken Seite kann nichts zugewiesen werden"!
Das scheint aber in XE6 noch kompilierbar gewesen zu sein, oder gibt es da auch noch einen Schalter der das zulässt?

Nein. Aber normalerweise kann man ein Object als const-Parameter übergeben, wenn man innerhalb der Methode dann nur seine Properties ändert. Was man nicht ändern kann (und auch niemals tun sollte, wenn der Parameter nicht als var oder out deklariert ist) ist, dem Parameter innerhalb der Methode ein neues Objekt zuzuweisen. Das ist auch dann ein konzeptioneller Fehler, wenn der Parameter ohne const deklariert wurde.

Es ergibt aber selten Sinn, Objekte als const zu übergeben, dam man immer noch die Methoden aufrufen kann, und immer noch Properties setzen kann. Der Zeiger (die Objektreferenz) ist const, nicht das Objekt selber.

Zitat:

Ich finde es übrigens sehr bedenklich, wenn eine DLL Funktionen exportiert, die Delphi-spezifische Datentypen wie TStrings verwenden. Sowas funktioniert normalerweise nicht ohne massive Probleme.

Genau. Wer Englisch lesen kann sollte wirklich mal meinen Artikel lesen: DLL dos and don'ts. Der zeigt, was man alles machen kann und soll und vor allem, nicht machen sollte.

[Rudy Velthuis]

Zitat:

Zitat von peterbelow (Beitrag 1429575)

Zitat:

Zitat von skoschke (Beitrag 1429560)

Etliche Proceduren, bei denen Objekte als const deklariert sind, die dann aber innerhalb der Procedure beschrieben werden!

Da kommt natürlich "der linken Seite kann nichts zugewiesen werden"!
Das scheint aber in XE6 noch kompilierbar gewesen zu sein, oder gibt es da auch noch einen Schalter der das zulässt?

Nein. Aber normalerweise kann man ein Object als const-Parameter übergeben, wenn man innerhalb der Methode dann nur seine Properties ändert. Was man nicht ändern kann (und auch niemals tun sollte, wenn der Parameter nicht als var oder out deklariert ist) ist, dem Parameter innerhalb der Methode ein neues Objekt zuzuweisen. Das ist auch dann ein konzeptioneller Fehler, wenn der Parameter ohne const deklariert wurde.

Es ergibt keinen Sinn, Objekte als const zu übergeben. Nur die Objktreferenz ist dann const, nicht die Properties und Methoden. Sowas wie const-Methoden wie in C++ gibt es für Delphi nicht.

Zitat:

Ich finde es übrigens sehr bedenklich, wenn eine DLL Funktionen exportiert, die Delphi-spezifische Datentypen wie TStrings verwenden. Sowas funktioniert normalerweise nicht ohne massive Probleme. DLL und Anwendung müssen auf jeden Fall mit der gleichen Delphi-Version kompiliert werden und sie müssen einen gemeinsamen Memory-Manager verwenden (z. B. in dem man beide mit run-time packages baut, und dann kann man auch gleich eine Package statt einer DLL erzeugen). Wenn man eine DLL haben will, die unabhängig von der Delphi-Version des Hostprogrammes ist und eventuell sogar von anderen Programmiersprachen aus nutzbar ist darf man nur API-Level Datentypen verwenden, oder zumindestens COM-kompatible.

[/QUOTE]

Wer Englisch lesen kann, sollte meinen Artikel über DLLs lesen: "DLL dos and don'ts". Da wird beschrieben, was man beim Schreiben von DLLs machen kann und sollte und vor allem, was man nicht machen sollte. Delphi-spezifische Typen sollte man tunlichst vermeiden.

[DieDolly]

Zitat:

Delphi-spezifische Typen sollte man tunlichst vermeiden.

Außer man schreibt die Unit für sich selber nur für Delphi.

[peterbelow]

Zitat:

Zitat von DieDolly (Beitrag 1429719)

Zitat:

Delphi-spezifische Typen sollte man tunlichst vermeiden.

Außer man schreibt die Unit für sich selber nur für Delphi.

Selbst das funktioniert nur, wenn man DLL und Hostprogramm mit der gleichen Delphi-Version und Sharemem baut.