BCB6 Linker error: Type index is bad in module
-
Hi zusammen,
seit gerade bekomme ich beim Linken meiner Anwendung folgende Fehlermeldung:
[Linker fatal error] Type index 492105755 is bad in module FF3DataFile.cpp
Abhängig von der Anwendung (Testing/Echte Anwendung) bekomme ich unterschiedliche Fehlermeldungen (index und Quelldatei), aber die Fehlermeldung ist die Gleiche.
Meine Anwendung besteht aus mehreren libs, unter anderem datafile.lib, in der sich die Datei FF3DataFile.cpp befindet. Der Compilevorgang der lib läuft ohne Fehler durch, lediglich beim Linken gegen die lib steigt der Linker jedes Mal mit der gleichen Fehlermeldung aus. Heute morgen ging´s noch ohne Probleme, ich habe der lib lediglich zwei neue Klassen hinzugefügt und einige marginale Änderungen.
Hat jemand ne Idee, was man da machen kann (bzw. wo man anfangen kann zu suchen)? Das INet hält sich dazu eher bedeckt, ich konnte bisher nichts Brauchbares finden.
-
Hast du das inkrementelle Linking deaktiviert?
Ansonsten versuche mal, die Anwendung mit ilink32.exe anstelle von ilink32.dll zu linken.
Zudem wurden seit C++Builder 6 recht viele Linkerprobleme behoben. Sofern du Zugriff auf eine neuere Version hast, versuche mal, dein Programm mit dieser zu linken.
-
Danke für den Hinweis Audacia, ich benutze schon den ilink32 des Codegear RAD Studio 2007 (Version 5.81).
Ich konnte den Fehler immerhin isolieren, indem ich die beiden Klassen aus dem Projekt genommen habe und jetzt schrittweise wieder einbaue.
Ich schreib noch was dazu, wenn ich den Fehler identifiziert habe.
-
Der Builder macht mich fertig...
Es liegt an der Klasse TRecordGreyLevelExposureDefinition, sobald ich ein Objekt dieser Klasse als Paramter verwende steigt der Linker aus. Ich habe nur noch zwei Vermutungen, die ich allerdings beide widerlegen kann:
-
Der Name für das Symbol ist zu lang ist und der Linker kommt deswegen ins Straucheln. Allerdings benutze ich noch eine Klasse, deren Namen zwei Buchstaben länger ist.
-
Die ersten n Buchstaben der Klasse unterscheiden sich nicht von einer anderen Klasse, sodass der Linker die genaue Klasse nicht identifizieren kann. Stimmt aber auch nicht, weil ich die gleiche Konstellation mit einer anderen Klasse, deren Namen länger ist, auch habe.
Aber ich bleib dran...
-
-
Läßt sich das auf ein Minimalbeispiel reduzieren?
-
Nein, leider nicht. Die Projekte sind relativ komplex und haben jeweils > 100 Klassen. Es gibt allerdings ein Update: Das Problem tritt nur im Debug Modus auf, der Release Build lässt sich kompilieren und läuft. Bin völlig planlos, woran das jetzt liegen könnte, werde das jetzt mal auf den 2007 portieren und gucken, was da passiert.
-
Schau mal hier.
http://qc.codegear.com/wc/qcmain.aspx?d=45071
das scheint ein ähnliches Problem zu sein.
-
Habe den QC Beitrag auch gelesen, aber das scheint was anderes zu sein. Ich kann den Fehler inzwischen bis auf eine Quelltextzeile bestimmen, hab aber keine Ahnung, wie da der Zusammenhang sein soll. Die Methode ist die Implementierung einer abstrakten Basisklasse, die das Besuchermuster implementiert, es sind allerdings wirklich viele virtuellen Methoden (für jeden Datensatztyp eine, dürften so um die 60 sein). Wenn ich die Behandlungsmethode für den o.g. Datensatztyp auskommentiere läufts durch, wenn die Methode mitkompiliert wird geht´s nicht mehr (selbst wenn ich den Methodenrumpf leer lasse).
Werde morgen mal probieren, ob es an der Anzahl der Methoden liegt, d.h. mal eine andere Methode auskommentieren. Vielleicht hat die VTable eine Maximalgrösse (was ich mir allerdings nicht vorstellen kann).
-
DocShoe schrieb:
werde das jetzt mal auf den 2007 portieren und gucken, was da passiert.
Das ist vermutlich der beste Ansatz.
Hast du mal den Kommandozeilen-Linker getestet? C++Builder 6 verwendet zum Linken meines Wissens die ilink32.dll, so daß das Ersetzen von ilink32.exe auf IDE-gesteuerte Builds keinen Einfluß haben sollte.
-
Die Portierung auf den 2007 war auf die Schnelle nicht erfolgreich, das hätte ich auch nur machen können, um zu sehen, ob der Fehler weiterhin existiert.
Ich benutze die DevExtension Tools, die IDE kompiliert und linkt nicht mehr selbst. Um sicherzugehen, dass auch tatsächlich die ilink32.exe benutzt wird habe ich die Linker DLL umbenannt.LÖSUNG:
Ich benutze jetzt nicht mehr den mitgelieferten Linker, sondern UniLink. Der meckert zwar, dass in manchen Objekt Dateien fehlerhafte Debuginformationen stehen, linkt aber korrekt. Jetzt muss ich nur noch nen bcc32 Ersatz finden, der die Debug Informationen korrekt erzeugt.
-
Wenn du unter forums.codegear.com dein Problem beschreibst und um Hilfe bittest, ist es nicht unwahrscheinlich, daß du von einem R&D-Engineer um ein Linkset gebeten wirst. Vielleicht wäre es dir dann möglich, ein Set an Objektdateien, an denen ilink32.exe scheitert, an CodeGear zu schicken? Gegebenenfalls kannst du ja die Funktionalität der wesentlichen Teile deines Programmes deaktivieren.
DocShoe schrieb:
Jetzt muss ich nur noch nen bcc32 Ersatz finden, der die Debug Informationen korrekt erzeugt.
-
Nachtrag, doch keine Lösung
ulink kann nicht alles linken, da die lib Datei zu gross ist. Bin jetzt genauso schlau wie vorher.
Ich werde mal beim Codegear Forum vorbeischauen, glaube aber nicht, dass mir da grossartig geholfen wird. Schliesslich arbeiten wir noch mit dem BCB 6, und das erste, was man mir da erzählen wird, ist, dass wir auf CG 2009 umsteigene sollen. Aber ich werd´s trotzdem mal probieren.
-
DocShoe schrieb:
Ich werde mal beim Codegear Forum vorbeischauen, glaube aber nicht, dass mir da grossartig geholfen wird. Schliesslich arbeiten wir noch mit dem BCB 6, und das erste, was man mir da erzählen wird, ist, dass wir auf CG 2009 umsteigene sollen. Aber ich werd´s trotzdem mal probieren.
Natürlich wirst du dort keinen Patch für C++Builder 6 mehr bekommen. Aber wenn dein Problem sich mit dem Linker von C++Builder 2007 oder sogar dem von C++Builder 2009 reproduzieren läßt, könnte es gut sein, daß es für die neueren Versionen einen Hotfix gibt.
Falls aber der Fehler von BCC verursacht wird, bleibt dir kaum anderes, als mal auf einen neueren C++Builder zu migrieren.
-
Heute hatte ich den Fehler auch, und wie es aussieht, lag es tatsächlich daran, daß ich ältere Delphi-Module mit einem neueren Linker verwendet hatte.
Die vollständige Portierung auf C++Builder 2007 sollte also helfen.