Unresolved external Linker fehler
-
Hallo zusammen,
ich habe eben auf das neue Radstudio 10.2 gewechselt und wie seit Seattle gewohnt lassen sich natürlich keine bestehenden Projekte auf Anhieb kompilieren, welche in den Projekteigenschaften als "Standalone EXE" konfiguriert sind.Ich bekomme plötzlich folgende Fehlermeldung:
[ilink32 Fehler] Error: Nicht auflösbares externes '__fastcall Idmessageclient::TIdMessageClient::TIdMessageClient(System::Classes::TComponent *)' referenziert von D:\PROJEKTE\C++\CASRA EXPORT\WIN32\DEBUG\FILE1.OBJ
Setzte ich "Mit Laufzeit Packages linken" lässt sich alles anstandslos kompilieren. Wie geht ihr vor wenn sich ein Projekt mit Laufzeit-Packages linken lässt und als Standalone nicht mehr?
-
Ich musste eine neue Projektdatei erzeugen. Das Nachtragen der fehlenden Indy Libs in die entsprechenden Zeilen der .cbproj hat leider nichts gebracht. So wie es aussieht, wurden auch einige Pfade zu den Sourcedaten geändert und konnten von meiner älteren Projektdatei nicht auflösbar geliefert werden. Ich verstehe nicht warum bei jeder neuen Version seit Seattle solche Ungereimtheiten auftauchen und erstmal das basteln aufkommt. Von XE4 bis XE8 musste ich nicht einmal was anpassen....sowas ärgert mich richtig
-
Zur Info:
Das Problem ist zurück und habe einen Fall eröffnet. Der findige Support von Embarcadero hat meinen Fall untersucht und festgestellt, dass im deutschen Compiler ein Bug enthalten ist und eine vielzahl von deutschen Libs ohne Konstruktoren erstellt wurden. Es kann also sein das auch andere Komponenten betroffen sind.
Aber man muss ja auf Teufel komm raus jedes halbe Jahr etwas rauspressen, koste es was es wolle......
Workaround: Die IDE auf English umstellen.
Bug wird im laufe des Tages getrackt.
-
Zero01 schrieb:
Das Problem ist zurück und habe einen Fall eröffnet.
Kannst Du bitte einen Link bzw die Id dazu posten?
Dann werde ich die 10.2 wohl noch etwas schieben müssen
MfG Stephan
-
Bisher habe ich nur eine interne ID und meine Meldung auf Embarcadero Quality fand noch keine Ressonanz. Meine Infos habe ich alle direkt vom Embarcadero Support Mitarbeiter. Die interne ID lautet RS-83349 und die auf Quality RSP-17700
Einen Workaround ohne die IDE auf English zu stellen habe ich hier im Indy Thread für die 10.1 gepostet.
-
Vielen Dank.
Der Link zum Bug: https://quality.embarcadero.com/browse/RSP-17700
Deine genannte Lösung funktioniert dann aber nur für Indy. Probleme mit weiteren Libs können dann trotzdem noch auftauchen.
MfG Stephan
-
Danke _Stephan_ für den Link. Ich konnte damit auch ein ganz anderes Problem "lösen":
Bei Rad Studio XE7 tritt bei Verwendung von Twine Compile, wenn man 64 Bit Programme erstellen will, immer ein Fehler auf (BCC64.exe reagiert nicht mehr), obwohl das Compilieren einwandfrei durchläuft, man muss nur jedesmal diesen nervigen Dialog wegklicken. Nachdem ich die IDE auf Englisch umgestellt habe, tritt das Problem nicht mehr auf.
Habe das Problem auch an JomiTech gemeldet.Edit: An Twine Compile liegt es jedoch nicht, sondern am BCC64.exe im bin/de Ordner. Ich habe einfach den BCC64.exe vom XE8 dorthin kopiert und nun funktioniert es einwandfrei (man kann aber auch die BCC64.exe aus dem Bin/en Ordner nehmen, wenn man nur XE7 hat, klappt ebenfalls). So kann die IDE auch auf Deutsch bleiben.
PS: In dem verlinkten Report wurde auch angegeben, dass das Problem in XE8 gefixt wurde.
-
Hallo,
der Embarcadero-Support hat mir folgenden WorkAround vorgeschlagen, der für meine Anwendung zumindest funktioniert:
"What you can do is copy the IndyProtocol.lib from the main lib directory to the DE directory, you will then be able to run the IDE in German, the only drawback will be that any error messages you log will be in English. "
mfg,
Christian
-
Zur Info: Im release 10.2 Update 1 ist das Problem nicht behoben worden.
-
Geht es jetzt nur darum, alte Projekt-Dateien zu importieren oder hast du solche (sprachabhängigen) Probleme auch, wenn du das Projekt neu erstellst?
Ich wäre ja froh, wenn mal alles englisch wäre. Ich wähle immer englisch und kriege trotzdem noch häufig deutsche (wirre compiler-) Meldungen um die Ohren geschlagen.
-
Der Bug ist auch in 10.2.2 2004 enthalten.
Kopieren der Libs in den DE Ordner war dann auch bei mir die Lösung. Danke für den Thread