VC2010 erzeugt linkerfehler, den gcc nicht erzeugt

PhilippM

Servus,

ich bin mit meinem Latein am Ende. Ich habe hier einen großen Haufen Code. Den ich nicht geschrieben habe. Deshalb für mich ein sehr undurchsichtiger Haufen.

Es kompiliert mit MinGW gcc 3.4 und gcc 4.5

Unter VS2010 kompiliert es auch, aber ich erhalte einen Linkerfehler. Verweis auf nicht existentes externes Symbol. Jetzt werdet ihr natürlich denken, irgendeine MinGW-spezialität, irgendeine externe Lib, die VS halt nicht hat.

Das ist es aber nicht. Sondern ich habe einen undefinierten Verweis auf eine Memberfunktion im Code selbst.

Das Problem, ich kann die Klasse nicht posten. Die hat > 8000 Zeilen. Auch die Vererbung ist total merkwürdig. Ich nehme an, der Linker kommt mit den virtuellen Basisklassen durcheinander.

Daher habe ich hier mal rauskondensiert, wie die Situation aussieht, in der Hoffnung, das jemand erkennt, dass das mit VS nicht funktioniert:

#include "fpc.h"
class Foo : private virtual BasicFunctions
{
public:
    Foo();

    void FooInit(FPC*, const int&, const int&, const double&, const double&);
};

class Bar: protected virtual BasicFunctions,
           protected SC,
           public ACM,
           protected Foo,
          protected FML
{
public:

    Bar( string, ...):Foo() { ... }
....

Was SC, ACM, FML sind, geht über mein Verständnis des Code hinaus.

Der Linkerfehler ist folgender:
Im Bar-Konstruktor kann er den Foo-Defaultkonstruktor nicht finden. Den braucht er natürlich, um Foo als Basisklassenteil von Bar erzeugen zu können.

Der Compiler findet ihn aber offenbar.

Ich weiß, dass die ganze "protected virtual" Mehrfachvererbung nach einem refactoring schreit. Fakt ist, der Code ist da draußen, er ist so wie er ist, mir gehört er nicht, aber ich muss ihn zum kompilieren bringen.

Ich kenne die Tücken von VS2010 überhaupt nicht. Deshalb poste ich es hier, in der Hoffnung, dass jemand VS besser kennt. Wenn jemand beim Draufgucken sieht "na klar, dass ist der VS2010 protected virtual bug", dann kann er mir vielleicht erklären, warum dieser Code nicht linkt. Was er mit mningw wie gesagt tut.

Ziemlich verzweifelt,
Philipp

PhilippM

So, bin ein bißchen weiter gekommen.

Ich habe festgestellt, dass der Linker recht hat. Wenn ich mit nm in das zugehörige object-file reingucke, ist da das entsprechnde Symbol tatsächlich undefiniert.

Der Kompiler baut die Funktion also nicht ins object-file ein.

Der Kompiler gibt aber keine Warning aus.

Was läuft hier schief?

Gruß,
Philipp

PhilippM

Das ist echt Detektiv-Arbeit!

Also: Die Funktionsdefinitionen werden offenbar nicht kompiliert.

Ich habe einfach mal in eine der Funktionen
Schrummmselbrumms reingeschrieben. In der Erwartung, dass der Kompiler motzt "Zeichensalat ist ein unkannter Name" oder so.

Aber er mault nicht. Das heißt, der Compiler bekommt diese Codestelle nie zu sehen.

Okay, mein Verdacht geht in Richtung eines wildgewordenen inklude-guards, vielleicht ein #endif dass vergessen ging und deshalb wird die Datei garnicht zu ende geparst.

Daher habe ich mir mit -E die Preprozessorausgabe von cl geben lassen.

Aber da steht der Code vollständig drin!!! Der Preprozessor baut die Datei richtig auf. Da steht dann

Foo::Foo() 
{ 
    Schrummselbrumms
    ich erzeuge mir einen Sytax-Fehler
    sinnvolleFunktion();
    sinnvolle = zuweisung;
}

und der Compiler meckert nicht? Wie geht das denn???

Philipp

PhilippM

Das ist die Kommandozeile, die diese ominöse Datei kompiliert:

cl -c -nologo -Zm200 -Zc:wchar_t- -O2
 -MD -EHsc -W3 -w34100 -w34189 -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_NO_
DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQ
T_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -DQT_NO_DYNAMIC_CAST -I"c:\Qt\4
.7.1-msvc\include\QtCore" -I"c:\Qt\4.7.1-msvc\include\QtGui" -I"c:\Qt\4.7.1-msvc
\include" -I"c:\Qt\4.7.1-msvc\include\ActiveQt" -I"release" -I"c:\Qt\4.7.1-msvc\mkspecs\win32-msvc2008" komische_datei.cpp

Bedeutet irgendeine dieser Optionen "Hör nach 3000 Zeilen auf zu parsen"???

EDIT: Kollege meint noch "Vielleicht ist die generierte Datei länger als 65000 Zeilen und da hört er das parsen auf?"
Kann sowas sein?

EDIT2: Kann die Datei ein encoding haben, dass dafür sorgt, dass irgendein unsichtbares Zeichen drin ist, wo der Kompiliervorgang abgebrochen wird?

PhilippM

Es ist abhängig von der LÄNGE DES DATEINAMENS.

What the f... ???

Wenn der Dateiname der Datei länger als 37 Zeichen ist, wird sie nicht mehr kompiliert.

Ich kann das reproduzieren.

Okay, wo habe ich gerade einen Bug gefunden? QT? nmake? jom? VC?

*Fassungslos an den Kopf greif*

37 ist beim Rechner keine auffällige Zahl.

Wie lang ist denn die Summe Laufwerk + Pfad + Dateinamen?

MfG f.-th.