LNK2001 und LNK2019 "unübliche" Ursache?!

[Calli82~]

Hallo,

habe folgendes problem, was mich mittlerweile schon viele Stunden beschäftigt hat. Inzwischen habe ich das Problem aber eingrenzen können und bin daher nun in der Lage, konkretere Fragen zu stellen:

Folgende Situation: Ich arbeite z.Zt. an einem etwas größeren C++-Codeprojekt mit MSVC2008 in der Professional Edition. Ich habe dort 2 Projekte, die für sich perfekt kompilieren und linken. Ziel ist es aber, den Code des 2. Projekts im ersten unterzubringen. Wenn ich also die entsprechenden Sourcen einbinde, kompiliert es zwar weiterhin, ich erhalte aber in dem Code, der ursprünglich in Projekt 2 war, nun Linkerfehler, die nachweislich aber nur in Kombination mit dem Code von Projekt 1 auftreten!

Hierbei handelt es sich um LNK2001 und LNK2019. Ich habe alle Bibliotheken eingebunden und Einstellung mindestens 3mal überprüft. Für sich genommen kompiliert und linkt der Code ja auch, es muss also an der explosiven Kombination des Codes beider Projekte liegen.
Es gibt in beiden Projekten Klassen, die gleich heißen, aber in unterschiedlichen Namespaces existieren. Kann es hier auch zu Konflikten kommen?

So langsam verzweifle ich an dem Fehler, kann mir jemand von euch einen neuen Tipp oder Anhaltspunkt geben? Was kann diese beiden Fehler noch auslösen?
Ich habe keine Ahnung, ob die Infos zur Rekonstruktion reichen, aber vielleicht könnt ihr mir ja irgendwie trotzdem helfen.

Danke sehr,
Calli

[Calli82~]

zusätzlich ist zu erwähnen, dass der Linkerfehler aber nach der Klasse im richtigen namespace sucht:

Fehler 2 error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: class webots::Servo * __thiscall webots::Robot::getServo(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?getServo@Robot@webots@@QAEPAVServo@2@ABV?$basic\_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)" in Funktion ""public: __thiscall FieldPlayer::FieldPlayer(int)" (??0FieldPlayer@@QAE@H@Z)". FieldPlayer.obj Nao.Win32 Webots.Broker

[Martin Richter]

Prüf mal wirklich die Deklaration der webots::Robot::getServo Funktion.

Evtl. stimmt die Signatur nicht. WEvtl. hast Du so was wie tsringverwendet und das eine Projekt ist Unicode unddas andere MBCS oder ähnliches.

[Calli82~]

Problem gelöst. ursache war folgendes:
In jeder Headerdatei befand sich eine Präprozessordefinition #ifndef ROBOT_HPP #define ROBOT_HPP
Die hatte ich zweimal, einmal in dem einem Projekt, einmal in dem anderen Projekt. Beim Kompilieren wurde die .obj entsprechend überschrieben von der zweiten Robot.hpp
Deshalb konnte er die Methode nicht mehr finden.

Danke trotzdem!

[hustbaer]

Wenn ein .obj File überschrieben wurde, liegt das nicht daran, dass du zweimal den selben Namen für einen Include-Guard verwendet hast, sondern daran, dass du zwei Source-Files mit dem selben Namen verwendet hast.
Beides ist problematisch, aber der Grund ist ein anderer.

Bei Source-Files mit dem selben Namen nennt der Compiler das Objekt-File gleich, und nur das zuletzt compilierte "überlebt". Daher fehlen beim Linken dann Funktionen. -> Linkerfehler

Bei gleichen Include-Guard Namen kann es passieren, dass der Inhalt eines der beiden Header-Files nicht "mitcompiliert" wird, und der Compiler daher die Deklarationen in diesem Header-File nicht "sieht" wenn er ein Source File compiliert welches beide Header-Files inkludiert. Dem Compiler fehlen dann z.B. Klassen- oder Funktionsdeklarationen. -> Compilerfehler